Viktor Szakáts wrote:
Right on the second page, I see syntactic sugar: a.x for a[ x ],
I'm not sure about the speed compared to a[ _NUM_INDEX ], but
it surely gives something I was missing a few days ago.
Yes, nice.
Regards
Alex
___
Harbour mailing
On Tue, 26 May 2009, Szak�ts Viktor wrote:
Hi,
Right on the second page, I see syntactic sugar: a.x for a[ x ],
I'm not sure about the speed compared to a[ _NUM_INDEX ], but
it surely gives something I was missing a few days ago.
You have such functionality from beginning though it's not
Hi Przemek,
You have such functionality from beginning though it's not enabled in
default core builds. You have to compile Harbour with HB_HASH_MSG_ITEMS
macro or use XHB library. The only one difference is that [x]Harbour
uses : not . as send operator so it will look like a:x not a.x
Using
On Tue, 26 May 2009, Mindaugas Kavaliauskas wrote:
Hi,
Sometimes I return in my mind to more general solutions, like changing
compiler to generate expression tree instead of code, typed variables, etc.
The last nice source of ideas I found is Lua virtual machine. In Lua 5.0,
VM was
they use:
ADD 3 1 2
yes but if you look carefully then you will find that number of registers
in such implementation is reduced to 256 what also reduce maximal number
of local variables which have to be less or equal (depending on code) to
the number of registers. To keep compatibility
Hi,
Sometimes I return in my mind to more general solutions, like changing
compiler to generate expression tree instead of code, typed variables, etc.
The last nice source of ideas I found is Lua virtual machine. In Lua 5.0,
VM was rewritten from stack based machine to register-based machine.
The last nice source of ideas I found is Lua virtual machine. In Lua
5.0, VM was rewritten from stack based machine to register-based
machine. This increased performance about 20%. Instead of:
PUSHLOCAL 1
PUSHLOCAL 2
ADD
POPLOCAL 3
they use:
ADD 3 1 2
Parrot code (VM for Perl 6) also use
Hi,
Since these kind of lines may appear in mass, such optimization
may result in code size reduction and speed increase.
Some more optimization ideas from the past: SUBSTR(), ASC( SUBSTR() ),
RETURN .T., RETURN .F., RETURN NIL
This is easy to do, but I guess it would increase speed very
The last nice source of ideas I found is Lua virtual machine. In Lua 5.0, VM
was rewritten from stack based machine to register-based machine. This
increased performance about 20%. Instead of:
PUSHLOCAL 1
PUSHLOCAL 2
ADD
POPLOCAL 3
they use:
ADD 3 1 2
Sounds very good, I've been
Hi Przemek and All,
It's common practice in Clipper/Harbour to use arrays to emulate structures:
---
#define _STRU_xVAR1 1
#define _STRU_xVAR2 2
#define _STRU_MAX_
LOCAL stru[ _STRU_MAX_ ]
stru[ _STRU_xVAR1 ] := 100
? stru[ _STRU_xVAR1 ]
---
In these scenarios, the array is indexed with a
On Fri, 22 May 2009, Szak�ts Viktor wrote:
Hi,
It's common practice in Clipper/Harbour to use arrays to emulate structures:
---
#define _STRU_xVAR1 1
#define _STRU_xVAR2 2
#define _STRU_MAX_
LOCAL stru[ _STRU_MAX_ ]
stru[ _STRU_xVAR1 ] := 100
? stru[ _STRU_xVAR1 ]
---
In these
Since these kind of lines may appear in mass, such optimization
may result in code size reduction and speed increase.
Yes, it will give some speed improvement but please remember that
we have limited PCODE list. Such problem does not exist in -gc3
output because we can use unlimited list of
12 matches
Mail list logo
