I think an important metric here is a comparison between your frame size, in this case 8192 and your bytes/group which was smaller than this. The number of frames used in primary space will tell you how many groups have another frame piggy-backed onto the default single frame they get when they are created.
I can't see that your example is badly sized, at least not so much that you would notice much if any speed improvement in resizing. In my experience, only the worst files actually cause a noticeable issue. The biggest issues are with.... bad programming. If you're having speed issues, I'd examine the code to look for bottle-necks. I have a funny story about a whole-file-process which, as it ran, output a status message on how many records it had processed, etc. Of course the file ran pretty quickly on new hardware, but the program still output a status line for *each* record processed. Record 1, 2, 3, 4, 5, etc up to 500,000 or whatever it was. The messages went by now, so quickly you couldn't really read them, so it was pointless. The whole process took about 2 hours. I changed that status to only output every 1000th record. The process from that point on, now took 10 minutes. The vast consumption of time, was just in printing status messages. Funny isn't it? Some things just don't scale well, when the hardware speeds up. Will J. -- Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
