Hi Michael,
Michael Meeks schrieb:
On Wed, 2006-09-13 at 12:22 +0200, Joerg Barfurth wrote:
Looks good.
I fixed your issues; thanks for the feedback, I attach the improved
patch. I also expanded the cache to some more fields that are broadly
constant, and split it into 1 cache per re-usable field. It saves some
more memory.
Yes, there are some patterns at the various levels which you can exploit
that way.
Looks fine at a cursory glance.
I'm also looking at the Subtree set usage:
http://go-oo.org/~michael/sortedsizes.ods
My concern here is the 16bytes per RBTree node (used in the set), at
least allocation here shows up on the profile.
Does that matter so much? I think SubTree instances should be shortlived
(they are built while loading the data, but discarded when the data is
flattened into the cache).
But cutting down on the allocations used (and maybe improving data
locality) would be nice.
It seems that 90% of these sorted sets are 8 items or less, and thus (I
suspect) rather fast to search, well, at least indistinguishable from
the order of the Set. The RBTree overhead for these <= 8 sets is ~250k
(malloc), overall 500k. I'm sure we can do better.
It might be worth checking what ends up cheaper: building a sorted array
and using binary search for lookups or going unsorted and using linear
search. The former might be worthwhile, because we would get the lists
out of the binary cache presorted.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
