[erlang-questions] Erlang to Python

Jon Watte jwatte@REDACTED
Sat Aug 6 22:55:12 CEST 2011


"We didn't know what we were doing in language A, so we re-wrote it in
language B."

However, it IS very easy to run into unexpected performance problems in
Erlang. To wit: we just profiled a slowdown in our application into the
supervisor module. Turns out, it uses a dict for its children, which ends up
generating lots of garbage (sort of n-squared) when adding/removing child
processes a lot to a supervisor with lots of children. We're going to not
use a supervisor for that case.

Which brings me back to a previous discussion: Most scripting languages have
convenient hash table classes. Python has dict. JavaScript has Object.
Erlang has dict, which isn't really O(1) for large sets, and gb_trees(),
which is asymptotically O(log n), and ets, which is close to O(1) -- and is
quite heavyweight.

I don't think it's possible to build an O(1) hash table on top of plain
erlang data structures (as each time you modify an element, you have to
re-create the top-level tuple). However, I imagine that with a C type, you
could build one, that could keep item generation counts or similar to keep
the amount of modified memory to a minimum. The question is: can it be done
without the overhead of ETS? Has it been done?

Sincerely,

jw

--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Sat, Aug 6, 2011 at 9:55 AM, Robert Virding <
robert.virding@REDACTED> wrote:

> Saw this on reddit. Any comments?
>
>
> http://code.mixpanel.com/2011/08/05/how-and-why-we-switched-from-erlang-to-python/
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110806/2b6a4f25/attachment.htm>


More information about the erlang-questions mailing list