On Aug 7, 8:17*am, Lambda <stephenh...@gmail.comwrote:
[worries about program possibly being slow snipped]
Before you go inventing a huge complicated scheme to
avoid something, do some measuring.
Define what you mean by "slow." Work out from your
algorithm what the time dependancy should be as a
function of the number of records. I didn't look too
carefully, but I thought it should have some parts
that were roughly linear. That is, double the number
of entries will make it take twice as long. (Maybe
worse, I see sort/merge actions.)
Then figure out how long is too long for a given
number of entries. Maybe it is not possible with
your algorithm no matter how fast your memory.
Whomp up a test case doing something as close as you
can manage to similar operations. See if it really
does become slow. Test it with different numbers of
entries. The code that does these tests does not
have to be complete or polished. Just make it do
some similar operations.
Only if it does become too slow should you consider
some alternative. Consider whether you can speed the
algorithm. Maybe you don't need as much stuff in
memory. Or maybe searching can be made faster.
Or any of several other things.
Example: Maybe you can keep some kind of key in
memory instead of the entire record. Then when
you have all your data read in, maybe you can do
the sorting/merging just on that key. Then you
can use the sorted/merged key list to write your
final data out.
If all that fails, only then start thinking about
doing big code twisting rewrites. And then, again
you need to measure. Again, whomp up a test rig
that tries things the way you think might work.
See if it really is faster. If it is faster, is it
fast enough? And does it stay fast enough with
larger number of records?
Socks
