Formula Fill Timing Issue
David Thompson
dthmpsn1 at uiuc.edu
Sat Feb 9 18:58:48 PST 2008
>At the risk of discovering another documentation dream, I ran a quick
>test (I just had to know. ;)
>
>The lookup db had 27,000 records with 269 fields. I formulafilled a db
>with 10,000 records. In the first test, the key field was the first
>field, the data field was the last. Total elapsed time: 135 seconds.
>Then, I moved the key field to column 50. Total elapsed time: 389
>seconds.
It wasn't a dream, but I don't think it was
documentation either. I think it was the email
quoted below. By the way, if each of those
databases had been 10 times as large, ie 270,000
and 100,000 records respectively, you could
figure on your test taking 100 times as long.
That would be 13,500 seconds (3 hours and 45
minutes) and 38,900 seconds (10 hours and 48
minutes) respectively.
Dave
Date: Sun, 01 Dec 2002 11:25:58 -0500
From: Mark Terry <terry at tcimet.net>
X-Accept-Language: en-us, en
To: qna at lists.provue.com
Subject: Re: lookup speed
Reply-To: <qna at lists.provue.com>
Sender: <qna at lists.provue.com>
X-Status:
X-Keywords:
Good call, Dave. The larger database has over 200
fields, and the keyfield in the slow example was
4 from the end. Moving it to the number 2 slot
makes it faster than the "fast" example. Thanks
to you and Scott for the input. Incidentally, I
tried reducing, and then eliminating the keyfield
alpha characters in the slow example and seemed
to show a marginal improvement, but not nearly
enough. Still, it makes sense to avoid lengthy
string prefixes in large db's.
So far, it looks like field position should be
viewed as the "prime" consideration for lookup(
speed.
Mark
P.S. If the lookup( functions behave as you've
described, it seems like they could be tweaked to
jump to the correct field position more directly,
doesn't it?
David Thompson wrote:
>I thought of something else that might contribute to the speed of a
>lookupall(. Put your key field as far to the left in the data sheet as
>possible. Panorama fields are variable width and each cell begins with a
>length code telling how long that particular cell is. In order for
>Panorama to find the second cell in any given record, it has to read the
>length code for the first cell, then it needs to read the length code for
>the second cell to find the third, etc. Panorama can jump instantly from
>the beginning of one record to the beginning of the next, but it can't
>jump instantly from the middle of one record to the middle of the next.
>
>Dave
>
More information about the Qna
mailing list