Re: ets:update_counter/3 taking a looooong time!

>>>>> "pm" == Peter-Henry Mander <erlang@xxxxxxxxxxxxxxxxxxxxxxx> 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