E
Eric Sosman
AndrewMcDonagh wrote On 08/04/06 18:12,:
Do both: Guess *and* measure. Guess beforehand, to inform
your design. Measure afterwards, to confirm (or refute) the
guesswork and to refine the implementation.
Recommended reading: "Programming Pearls" by Jon Bentley.
Patricia said:Eric Sosman wrote:
...
Memory saved by using parallel arrays: 18*N*N - 60*N - 16
bytes -- roughly speaking, 18*"huge" bytes. A savings of
18*"huge" bytes isn't a "micro"-optimization.
Note, also, where those bytes are. The 8 bytes per object overhead, and
the padding to bring the object size up to a multiple of 8 bytes are
likely to be interleaved with payload data. They will occupy cache
space and use memory bandwidth, much more expensive than the same
overhead in a separate structure.
This isn't to say that the optimization *should* be done,
of course. But the size of the potential savings is large
enough to influence the design from the outset: [...]
I completely agree...unless the usage of the array is a one time
occurrence and the real bottle neck in the system is a simple loop
somewhere that gets executed continually, which really should be a hash
table lookup.
Measure to find the problem area - dont guess.
Do both: Guess *and* measure. Guess beforehand, to inform
your design. Measure afterwards, to confirm (or refute) the
guesswork and to refine the implementation.
Recommended reading: "Programming Pearls" by Jon Bentley.