Re: Locality of allocations
From: Eric Taylor (et1_at_rocketship1.com)
Date: 09/20/05
- Next message: QNils_O=2E_Sel=E5sdal=22?=: "Re: How to find memory leaks -- linux 64 bit"
- Previous message: Divick: "How to find memory leaks -- linux 64 bit"
- In reply to: Kasper Dupont: "Locality of allocations"
- Next in thread: Kasper Dupont: "Re: Locality of allocations"
- Reply: Kasper Dupont: "Re: Locality of allocations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 19 Sep 2005 23:06:24 -0700
Kasper Dupont wrote:
>
>
> So I have an idea about splitting it up. The most
> practical way to split this structure will give me a
> 28 byte structure with a pointer to a 528 byte char
> array.
>
In your other posts, you seem to have dealt with
the issues of locality of the smaller pieces, yet
are still unsatisfied with the performance.
I was struck with curiosity about this 528 byte
char array, which you did not describe any further.
A young grad student once remarked to me, "Virtual
memory is great, as long as you don't use it".
So, I was wondering if your efforts might be better spent
looking at a way to reduce/compress your memory - a tradeoff
of more cpu cycles to avoid paging. For example, do you need the
528 to be fixed in size. If you only access these sections
infrequently, and it's a batch run I think you said, could you
do some simple data compression on these (are they mostly
zeros etc.). Is this data text, or lots of differnt small items.
Do these change often, or are they mostly read/only?
Is this tree used for searching? Might you avoid touching many
nodes by using a hash table instead? Why did you choose a
tree? Of search/insert/remove/create/delete etc., which operations
are used most often.
Anyway, you've probably thought of all this, but sometimes one
forgets the old adage, if it hurts when I do this, well, then don't. :)
eric
- Next message: QNils_O=2E_Sel=E5sdal=22?=: "Re: How to find memory leaks -- linux 64 bit"
- Previous message: Divick: "How to find memory leaks -- linux 64 bit"
- In reply to: Kasper Dupont: "Locality of allocations"
- Next in thread: Kasper Dupont: "Re: Locality of allocations"
- Reply: Kasper Dupont: "Re: Locality of allocations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|