Re: Slow memory access, Not understood when using integer@(mem address)

[Jussi Lahtinen <jussi.lahtinen@xxxxxxxxx>]

This:  Integer@(mptr) = Integer@(mptr) + 1
does a lot more than this: vptr.counter = vptr.counter + 1

They are not quite equal.
First one fetches Gambas integer from the memory address twice and then
adds one. The other one does everything completely within Gambas. IE adds
one to the variable in Gambas.


Jussi



On Thu, Sep 24, 2026 at 12:03 AM Brian G <brian@xxxxxxxxxxxxxxxx> wrote:

> On 9/23/26 13:36, Brian G wrote:
> > I have attached a small project that tests the access speed to memory
> > using integer@(memory address), as used for Linux library interfaces.
> > I am sorry but 44 times slower than access through a struct pointer is
> > just a bit much to accept!
> > Using this structure and allocating a data space
> > Public Struct myint
> >     counter As Integer
> > End Struct
> > mptr=alloc(100)
> > Here is an example using integer@(xx) compared to accessing thru a
> > structure 1 million times
> >
> > Test Speed to Access script Variables using integer@ptr access method,
> > no locking
> > using: Integer@(mptr) = Integer@(mptr) + 1
> > Total time 4.40942561195698
> >
> > Test Speed to Access script Variables using struct direct access
> > method, no locking
> > dim vptr as myint = mptr
> > using: Inc vptr.counter and tested with vptr.counter = vptr.counter +
> > 1, same results
> > Total time 0.098687710007653
> >
> > Struct access is 44.6810829482192 times faster than integer @ access
> > to the same memory address
> >
> > Can this be fixed, it is pretty bad!
> >
> Update
>
> using fast unsafe the values are interesting so normal is about 1442
> times slower than fast unsafe version
>
> Hello world
> Test Speed to Access script Variables using integer@ptr access method,
> no locking
> Total time 0.003050090977922
> Test Speed to Access script Variables using struct direct access method,
> no locking
> Total time 0.041397490072995
> Struct access is now 13.5725427118894 times slower..... confusing such a
> big difference
>
> --
> ~~~~ Brian
>
>