I want to know _all_ of these little speed tidbits, particularly the FB^3 ones. Who has a significant compilation? Has anyone compiled them all into a set of text files or into a searchable database? I volunteer to create and host a searchable filemaker database on my server, dedicated solely to FB^3 speed snippets (not general how-to stuff, but genuine this-way-is-the-fastest-way stuff). To search, type a word or select a category, it finds all matches. To submit, pick a category, paste the snippet, easy as pie... ..... There, my money is where my mouth is. It's ready to go. I seeded it with 24 of my own FB speed snippets. Some are FB^2 and that's ok, but mostly I want FB^3 stuff. I defined these categories: Files, Memory, Calculations, Edit Fields, Registers, Algorithms, and Fastest Way. (If you find any errors let me know.) Here's the URL for searching: http://www.internetyx.com:591/fb/search.html Here's the URL for contributing (requires a username/password, email me first): http://www.internetyx.com:591/fb/submit.html If someone has a significant collection of speed snippets, I would be happy to do the grunt work of entering them in the database. --Steve When I checked my e-postbox, I found e-mail from Robert Purves <robert.purves@...> sent on 9/23/00 6:28 AM that said: > >> I would like to know the difference between: >> 1) POKE LONG([Handle&]), 75000 >> and... >> 2) Handle&..0& = 75000 > >> #2 is _much_ faster. Why ? >> Isn't POKE totally useless ? :-D >> (I know I'm wrong, but why?) >> Also, do I need to lock the handle before >> using the 2nd function ? > > DIM myHandle as HANDLE > myHandle = fn NewHandle(100) > > Then > POKE LONG([myHandle]), 75000 becomes: > > lwz r3,0x0508(r14) ; myHandle > lwz r3,0x0000(r3) ; [myHandle] dereference handle > subi SP,SP,0x0004 > stw r3,0x0020(SP) ; store address on stack > lis r3,0x0001 ; 65536 > addi r3,r3,0x24F8 ; + 0x24f8 = 75000 > lwz r4,0x0020(SP) ; load address from stack > addi SP,SP,0x0004 > stw r3,0x0000(r4) ; store 75000 in dereferenced address > > myHandle..nil& = 75000 becomes more efficient code: > lwz r3,0x0508(r14) > lwz r3,0x0000(r3) > mr r31,r3 > lis r3,0x0001 > addi r3,r3,0x24F8 > stw r3,0x0000(r31) > > POKE LONG is slower because of the extra store and load. > > The same is true with a pointer. For example, POKE myPtr,1 is slower > than myPtr.nil`` = 1 > > POKE and POKE WORD etc are therefore not used by savvy speed-seekers. > > > PEEK and PEEK WORD, etc, do not show this disadvantage. > x = PEEK(myPtr) produces the same assembler code as x = myPtr.nil`` > > > You don't need to lock the handle before either POKE LONG([myHandle]),x > or myHandle..nil& = x, since no memory-moving can occur between > dereferencing the handle and writing something to the dereferenced address. > > > Robert P. > > > > > > > > -- > To unsubscribe, send ANY message to <futurebasic-unsubscribe@...> > --Steve _____________________________ Steven J. Stratford, InterNetyx.com Visit The CGI Store for Mac/WebStar Servers! http://www.internetyx.com Need custom CGI programming for Mac/WebStar? Email me: sstrat@... _____________________________