Craig Black wrote:
> In case it wasn't already mentioned, use Tango instead of Phobos.  It has a faster GC.
> 
> -Craig

If your supposedly speed-efficient program is GC-bound, you have bigger problems than Tango or Phobos. :p

 --just downs' 5¢

Robert Fraser wrote:
> Robert Fraser wrote:
> 
>> - Try using memory-efficient data structures like Judy (
>>   http://judy.sourceforge.net/ ).
> 
> 
> Or maybe not:
> 
> http://www.nothings.org/computer/judy/

Well, the guy certainly saw a lot of effort trying to prove that Judy isn't cool. I'm not impressed.

Especially the consistent performance of Judy_seq and Judy_64 was quite amazing. If one wants predictable and scalable performance, that additionally is excellent, then that is my choice. I assume that, if one knows the data is in order, then Judy is good, and for unordered data (i.e. that which really needs hashing) a hash is better. (Gee, surprise.)

So, it shows two things: Firstly, if you have a choice, then benchmark, benchmark, and benchmark. Don't just read ads or believe the buzz on the street. Second, every job has its tool.

IIUC, sparse arrays would be a dream application for Judy, especially if they can be filled in order. Or partial order.

downs wrote:
> Craig Black wrote:
> 
>> In case it wasn't already mentioned, use Tango instead of Phobos.
>> It has a faster GC.
> 
> If your supposedly speed-efficient program is GC-bound, you have
> bigger problems than Tango or Phobos. :p

Seriously, there's a sharp and definitive point to that.

From what I hear (since I still haven't tested Tango, my appologies to the Tango Team), Tango is an excellent library, and faster than Phobos in most things.

But it really is true: if your program uses new (and 'abandon') enough for the GC to become a major decider on library choice -- then you really should halt all work and step back. You literally have something else to worry about than the choice between libraries.

That choice can bring you (what? My guess is) maybe a 10-20% speedup in the *GC* things, which probably is only 2-5% of total execution time (since your program probably does a lot more than just wait for the GC to finish)!

So, staying with whatever was your library (Tango or Phobos), and spending the time on figuring out why your program thinks it's got a "frequent flyer plan" with the GC, would be time much better spent.

Speedups of 2x to 10x should not be impossible *in such a* situation. (For those who've suffered the contemporary school system, that's like 100% to 900% better.)

Georg Wrede wrote:
> Robert Fraser wrote:
>> Robert Fraser wrote:
>>
>>> - Try using memory-efficient data structures like Judy (
>>>   http://judy.sourceforge.net/ ).
>>
>>
>> Or maybe not:
>>
>> http://www.nothings.org/computer/judy/
> 
> Well, the guy certainly saw a lot of effort trying to prove that Judy isn't cool. I'm not impressed.
> 
> Especially the consistent performance of Judy_seq and Judy_64 was quite amazing. If one wants predictable and scalable performance, that additionally is excellent, then that is my choice. I assume that, if one knows the data is in order, then Judy is good, and for unordered data (i.e. that which really needs hashing) a hash is better. (Gee, surprise.)
> 
> So, it shows two things: Firstly, if you have a choice, then benchmark, benchmark, and benchmark. Don't just read ads or believe the buzz on the street. Second, every job has its tool.
> 
> IIUC, sparse arrays would be a dream application for Judy, especially if they can be filled in order. Or partial order.

While I often do sequential inserts into an associative array, I rarely do sequential reads (Unless I'm enumerating through all the values). So, I guess every structure has its place, and Judy is much more memory-efficient. But that benchmark tells me "in common usage (where data is unordered), Judy is less efficient than a hash table".

Craig Black wrote:
> In case it wasn't already mentioned, use Tango instead of Phobos.  It has a faster GC.
> 
> -Craig

If you really need the speed boost (I also say: profile first), then
consider using manual memory management. It may be more difficult, but
no pain, no gain.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D