[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Slow memory access, Not understood when using integer@(mem address)
[Thread Prev] | [Thread Next]
- Subject: Re: Slow memory access, Not understood when using integer@(mem address)
- From: Benoît Minisini <benoit.minisini@xxxxxxxxxxxxxxxx>
- Date: Fri, 25 Sep 2026 09:01:11 +0200
- To: user@xxxxxxxxxxxxxxxxxxxxxx
Le 23/09/2026 à 22:36, Brian G a écrit :
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 timesTest Speed to Access script Variables using integer@ptr access method, no lockingusing: Integer@(mptr) = Integer@(mptr) + 1 Total time 4.40942561195698Test Speed to Access script Variables using struct direct access method, no lockingdim vptr as myint = mptrusing: Inc vptr.counter and tested with vptr.counter = vptr.counter + 1, same resultsTotal time 0.098687710007653Struct access is 44.6810829482192 times faster than integer @ access to the same memory addressCan this be fixed, it is pretty bad!
It's because each call to 'Integer@()' (or the other functions of the same family) install and uninstall signal event handlers to catch any possible illegal memory access, so that the interpreter does not crash. There is no optimization at all.
The 'xxxx@()' functions are just there to be JIT compiled. They are not supposed to be used in a "normal" program.
I will see if I can optimize the signal event handler management, if it's possible.
Regards, -- Benoît Minisini.
| Re: Slow memory access, Not understood when using integer@(mem address) | Benoît Minisini <benoit.minisini@xxxxxxxxxxxxxxxx> |
| Slow memory access, Not understood when using integer@(mem address) | Brian G <brian@xxxxxxxxxxxxxxxx> |