In observing this thread the words 'page size' caught my eye. In 1978 I remember a much older programmer working with me at Microdata (sic) reading very closely the Basic compiler output generated with the MAP option. Microdata's compiler didn't (doesn't) generate the necessary file helpful with debugging programs automatically so you had to specify with the (M option to generate it. It produced the variable table and laid out the basic code lines as they were spread out over the object code record.
I recall him reviewing a FOR...NEXT loop that had the FOR part in one frame and the NEXT part in another and he was spending time trying to put compilable code (not comments) in front of the FOR section in the hope that the both the FOR and NEXT were in the same frame. This may have had the moniker "Frame Faulting". Mainframes called this a Core Dump. So he would code and compile and review, code and compile and review until he felt it was right. Perhaps his age at the time (50?) indicated a respect for the incredibly precious resources that he was used to and the disciplines that he had to adhere to. In the last 28 years of my MV programming I have never recalled having to be so anal as to perform such a lower-level observation for such an unmeasurable improvement. I could never count the number of times I typed the word "BASIC" I don't advocate sloppy programming or poor file design techniques. But with today's incredibly fast, fast, fast, fast and large, large, large systems, I believe there is also an unmeasurable element to over analyzing the tweaking. While it's easy to take an academic approach to the micro-managing of each CPU cycle and disc read, at some time it just really doesn't matter. Granted if you create a file with a mod of 1 and try to cram 10 MB into it, the system will accomodate this gross error and reward you with a slower file. But if the file was created with a mod of 1001 (sic) and it should have been 1401 (sic), how measurably different is the delay with the 40% undersized file of 1001? (PS for those who don't know, (sic) means example. Don't reply with lessons on prime numbers. It's just an example). I tried this years ago on a single user system (multiple user systems are much harder to truly measure with the other user's affect). IIRC I had a file that needed a 3001 (sic) modulo and I loaded it from tape into different file sizes ranging from 11, 101, the calculated 3001 and even 15001. I performed some crude timing tests, ie sorting, read/re-write etc and came away with the impression that it really doesn't matter unless it's tremendously undersized. The 11 size file was the poorest but the 101, 501 and 15001 were suprisingly close to the 'preferred' 3001. IIRC even having some non-prime modulos near 3001 and it didn't matter either. I haven't tried this test recently but I can imagine that the results would be quicker but the shot-group would be the same if not tighter. I don't know about U2 systems, but D3 systems have long dropped the separation value in creating files with the assumption of '1'. That closes that chapter on file calculations. I can't imagine justifying the process to analyze and re-analyze this today. Perhaps I'm wrong and someone managing a 10,000 user system will babble about every precious CPU. But for the rest of us it is an entertaining distraction that would be hard to cost-justify. We don't have a 10 MB hard drive system supporting 16 users with 32K of core memory anymore. Today's numbers are downright staggering in the MV world. My 101,1 cents Mark Johnson ----- Original Message ----- From: "Anthony W. Youngman" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, October 18, 2006 5:06 AM Subject: Re: [U2] VOCLIB and keeping VOC entries Short and Small, IM & RM > In message > <[EMAIL PROTECTED]>, Adrian > Merrall <[EMAIL PROTECTED]> writes > >> And on, and on, until the particular bit of data is found. > >> So... (this being one of the overwhelmingly elegant things about the > >> Pickuverse) this means that in a properly sized hashed file NO MATTER > >> HOW BIG it only takes one disk read to get to any record given a known > >> key. Ask your local Oracle/Sybase/Informix/SQL Server DBA if they can do > >> that. Stand back though, they tend to sputter alot. > > > >But won't this only work if your data fits into the modulo that > >matches your page size? If your data is lumpy and doesn't nicely fit > >into the page size/file modulo selected you get level 1overflow and > >more disk IO. > > > The stats I've come across (yes, they're old, they came from Prime) say > that PROVIDED Adrian's "properly sized" caveat is followed, even when > you have level 1 overflow and lumpy data, your 1 merely increases to an > average of 1.05. In other words, 19 out of 20 attempts still hit first > time... > > Cheers, > Wol > -- > Anthony W. Youngman <[EMAIL PROTECTED]> > 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the > thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man > lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 > Visit the MaVerick web-site - <http://www.maverick-dbms.org> Open Source Pick > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
