OpenEuphoria

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
>
>
>
>