RE: poke - peek Speed?
- Posted by rforno at tutopia.com Nov 16, 2002
- 441 views
It is *much* slower this way, as it is pointed out in the docs. The only way I've found to improve the performance is: sequence Addr2 Addr2 = {Addr1, 2} ..... return peek(Addr2) as it was suggested by Rob in a post in answer to mine. However, this only makes the 'division' and the 'peek' methods exactly equal in performance. Regards. ----- Original Message ----- From: Don Phillips <EuNexus at yahoo.com> Sent: Friday, November 15, 2002 12:40 PM Subject: RE: poke - peek Speed? > > > Yes, it is correct, because I will provide to it numbers in the range 0 > > - > > 32767. But you are right: I am performing less calculations than the > > poke4 - > > peek version. However, the poke4 - peek version surely works by shifting > > instead of dividing, or merely moving bytes around, so it should be > > faster. > > Don't you think so? > > Ahh yes, with only that number range the algo is indeed correct. The > poke4 - peek version doesnt work by either shifting or dividing. poke4 > writes a single 32 bit dword from any memory address where poke reads 8 > bit byte values (in this case two of them). It is simply direct memory > access with no math involved. > > The slow up (as pointed out by Mr Craig) is this line: > return( peek({Addr1,2}) ) > > I dont really understand the difference between peek({Addr1,2}) and > peek(Addr1) & peek(Addr1+1), they both build a sequence. But the second > version just about matches the results you would expect so internally it > must be be more efficient. > > function to2bytesa(integer u) > poke4(Addr1, u) > return( peek(Addr1) & peek(Addr1+1) ) > end function > > > >