ets:update_counter/3 taking a looooong time!
Scott Lystig Fritchie
fritchie@REDACTED
Thu May 1 00:53:48 CEST 2003
>>>>> "pm" == Peter-Henry Mander <erlang@REDACTED> writes:
pm> The attached gives the output of fprof, and the last line
pm> indicates that all the time is spent waiting for
pm> ets:update_counter/3 to return a new transaction ID to
pm> megaco_config:incr_trans_id_counter/1.
I've got two theories.
1. Has your Erlang VM's size grown so large that your OS has started
paging memory to disk to make room? Or has some other OS process
started hogging CPU cycles?
Er, well, those are easy guess, and surprisingly easy to forget
about if you're distracted by other things.
2. Is your OS platform FreeBSD (or perhaps one of the other *BSDs)?
I've been doing some simple ETS benchmarks lately, and I've noticed
really weird behavior of ets:delete() (deleting lots of items in a
table or deleting an entire table at once) with FreeBSD 4.7-RELEASE
and 5.0-RELEASE and Erlang R9B-1. If the table is large (tens of
thousands to millions of items), the delete operation can take up
to 40 times (!) longer than running on the exact same hardware
under a "modern" Linux (Mandrake 9.1 distribution).
This was so surprising to me that I tried it on two different
machines, a Pentium III laptop and an AMD XP+ desktop. Same thing:
FreeBSD was horrible in the delete case, Linux was not.
I haven't chased down the final answer (hopefully I'll get back to
finding the answer and propose a fix) ... but "gprof" analysis
strongly suggests that libc's free() is the culprit. Bummer.
-Scott
More information about the erlang-questions
mailing list