our original discussions until now, I think it may be more worthwhile to
figure out how to make _all_ 18000 constants available to Win32::GUI
programs, without paying a huge price in memory. Those constants that
actually get used get cached in the stash anyway...
If speed isn't the issue then a binary search has ...
It is difficult or impossible to do a binary search of compressed data...
so if space is the overriding issue, compression is the overriding answer,
and linear searching becomes the only practical search technique. To avoid
linear searching of the complete set, a
My 2 cents:)
We have 2 issues:
1) Performance.
2) Memory requirements.
Personally, the performance issue is a none event. I did some timings a
while back, and the constant lookup logic could be several orders of
magnitude slower than the current solution and it wouldn't make any
difference to how a Win32-GUI application would perform. This is because the
constant code isn't called often enough to make any difference.
Personally, the memory issue is a main problem. I like the idea of having
all 18000 constants available to Win32::GUI (if all the constants are
available, then the module would also be useful for none Win32-GUI modules),
but at what cost? 50k? 100k? 200k? Think about it for a moment - what would
you sacrifice? Perhaps it's worth setting some target to aim for?
The binary search is a good idea - and I can think of a ways to make it work
with compressed data - but we're still talking quite a lot of memory. If
each constant (including the text and value) is:
average 10 bytes each = total 180,000 bytes
average 20 bytes each = total 360,000 bytes
...
Now, for some cases, 360k is a drop in the ocean - my app runs at 50 meg
before it's done anything, with the exe coming in at 6 megs - but for a 20
line utility script, having to load the dll holding the constants could be
over-kill...
Perhaps less common constant text/values could be stored as a file, with a
fast binary search lookup?
Cheers,
jez.
