in reply to Re: Re: optimize this code?
in thread Optimization of DB_File sorting and processing code

The slowest thing by far is the matrix building line

That surprises me. Since that's the case, you might consider an alternate matrix representation. Is it important that the column values be in order by key? Will there always be the same number of {key, value} pairs in each of the .db's?

If each .db has the same number of {key, value} pairs, you can build the array in a single large nFile x nKeys vector, which might let you can some creation time at the expense of later access time.

Replies are listed 'Best First'.
Re: Re: Re: Re: optimize this code?
by Evanovich (Scribe) on Feb 09, 2002 at 14:34 UTC
    Yes, each hash has exactly 6265 entries. The matrix will always have that many rows: the number of columns will change though depending on the situation. Can you elaborate on this alternate matrix representation? I don't know what that means. Thanks so much for your help!