HP3000-L Archives

July 1997, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jerry Fochtman <[log in to unmask]>
Reply To:
Jerry Fochtman <[log in to unmask]>
Date:
Mon, 28 Jul 1997 09:21:39 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (23 lines)
At 01:36 PM 7/28/97 +0000, Ewart North wrote:
>For example, I have a program (inherited, old but working) which links
>from a KSAM file into an Image database.  The KSAM file has about 600,000
>records in it and a capacity of 690,000.  The program runs for 399 cpu
>secs for the specified selection.  If the KSAM file is then rebuilt so
>that the 600,000 now exist in a file of capacity 900,000, then the same
>selection reduces to 360 cpu secs.

I wonder if by 're-sizing' the KSAM file the rebuild has resulted in
the data being placed in better locality, resulting in somewhat better
performance.  You didn't indicate how long it had been since the file
had been re-built.  I wonder if you re-built it again, lowering the
capacity back to 690,000 if you achieved the same performance?  This
would suggest that the act of re-building the indexes themselves, using
ordered input, resulted in more efficiency rather than the overall
excess capacity...

Although 6 minutes CPU time seems awful excessive (you did indicate
seconds vs. milliseconds....)  Perhaps there are other contributors
to the problem, such as file fragmentation, etc.  Does the timing you've
provided represent only the KSAM call, or are there other activities
included in this measurement?

ATOM RSS1 RSS2