[erlang-questions] Erlang Cost Model

[zxq9]

On 2015年9月17日 木曜日 11:56:47 you wrote:
> On 09/17, Eric des Courtis wrote:
> >Regardless if concurrency and parallelism plays a role *I still need to
> >know if an operation in a sequential process I am working on is O(1) or
> >O(n)* or am I missing something?

So that comment I made about "case 1" where there are a "lot of options already"...

> These values are way more worthwhile as a property of libraries than 
> language, since they're far more impacted by the choice of algorithm 
> taken there.
> 
> Let's look at a few modules:
> 
> 1. Queue
> 2. Maps
> 3. Dict
> 4. Array
> 5. Gb_trees
> 6. Sets
> 7. Gb_sets
> 8. ETS
> 9. Orddict
> 10. ordsets
> 11. sofs
> 12. Digraph
> 13. lists:key* functions
> 14. Proplists

...

> 1. Message receiving (non-selective)
> 2. Message receiving (selective)
> 3. Sorting (lists:sort)

These are costs specific to a particular operation happening on its own time, but tell you nothing meaningful about your system as a whole because all of this stuff is going on at once in different processes at different times. Sometimes you are in the situation where doubling your processing speed just means adding more cores. Sometimes not. You will either *know* at the outset of a project or *have no idea whether this is true* until you actually have something up and running that you can measure. Usually it is the latter.

Very often you will find yourself able to approach a concurrent ideal after you've already got something implemented that does basically what you want, but not before. This is true whether or not you've got months of paid time to toy with an idea (HA HA! Like *that* ever happens!). It is nearly always faster to experiment with a prototype in Erlang than to just muse about it until the concept is perfect. Once you have a prototype, tweaking it is easy, and when that exists you can already measure stuff for real. This is why I am calling the *unqualified* utility of cost models into question.

-Craig