OpenEuphoria

2. Re: bottlenecks :)

• Posted by "Cuny, David" <ATB.DCUNY at HW1.CAHWNET.GOV> Mar 27, 1997
• 943 views

I suspect that the problem is the conversion to and from Euphoria data
types. Depending on what you are doing, you may be able to skip past a lot
of Euphoria's type casting.

You can now use mem_copy() to move raw memory from one buffer location to
the next. This will speed up peek() and poke(), since there is no conversion
to sequences in between. I did that to my graphic screen save and restore,
and got a phenomenal speed increase.

There is also a mem_fill() type command, for initializing memory (instead of
building arrays).

You might also consider writing your own assembly AND and OR routines that
access the memory buffer directly, and again bypass the conversion to
Euphoria data types. You might find a prototype in some of Jacques' code.

If you are using disk read/writes to read and store the data (I'm thinking
this is related to your compression program), you might also consider
Jacques disk code to write directly to your buffers, again skipping
Euphoria's type conversion routines.

I haven't tried running or timing this, but often another option you have is
to build a table lookup for your functions (ANDs and ORs). It would be 256 *
256 bytes long per table, but once built, you could use the two value to
index into the table. For example, something like this (i haven't bothered
to test the code):

 -- START OF CODE

 -- build OR lookup table
   sequence or_table
   or_table = repeat( 256, repeat( 256, 0 ) )
   for i = 0 to 255 do
      for j = 0 to 255 do
         or_table[i+i][j+i] = or_bits( i, j )
      end for
   end for


 -- build AND lookup table
   sequence and_table
   or_table = repeat( 256, repeat( 256, 0 ) )
   for i = 0 to 255 do
      for j = 0 to 255 do
         and_table[i+i][j+i] = and_bits( i, j )
      end for
   end for

 -- example of usage
 -- AND( 3 + 0 )
   x = and_table[3+1][0+1]

 -- END OF CODE

Notice that you have to add 1 to each index, since an index of zero in
Euphoria will not work.

If this turned out to give you the speed you wanted, you could always load
the table to disk instead of calculating it. You could then load it into a
buffer, and use something like:

     x = peek( and_table_buffer + ( x1 * 256 ) + x2 )

You could probably optimize the * 256 using a series of * 2's, which I think
Euphoria performs as shifts automatically (I think...).

Hope this helps.

 -- David Cuny