[Gambas-user] Getting Gambas up to speed.

[Michael Isaac]

Benoit Minisini wrote:

>On Wednesday 06 July 2005 01:45, Joseph Murphy wrote:
>  
>
>>Hi Michael
>> I did some testing with do while and for next loops and it does seem to be
>>rather slow.  To do a for next loop that does nothing except increment the
>>counter it took 14 seconds to go from 1 to 10000000.  I only tested up to
>>ten million but 14 seconds does seem slow and gbx2 was using 99 percent of
>>the cpu according to top.
>>
>> I then checked out your DeepSpace project.  I found something different
>>with it.  gbx2 was taking only 13 percent of the cpu time and X was taking
>>85 percent.  I think there are multiple issues with the speed problem.
>>
>> I then checked out the optimization of the gambas compile and it is being
>>optimized for size.  I haven't had the time to see if there is an increase
>>if it is optimized with -O3 instead of -Os but I doubt that there will be
>>much difference.
>>
>> This does seem to be something that needs further investigation.
>>
>>Joseph
>>
>>    
>>
>
>I know that looping is slow in Gambas, but I think it is more interesting to 
>test the other parts of the language (arithmetic, strings, ...) because a 
>program that loops is only a buggy program ;-)
>
>I looked at DeepSpace, I modified it to run 500 objects, and I have the same 
>conclusion. Drawing is slower than calculating in this case, but it mainly 
>depends on your graphical driver, as the drawing area is updated (i.e. the 
>cached pixmap is redraw to the screen) at each frame.
>
>Regards,
>
>  
>
Benoit,

You failed to see the point.  The point was that gbx2 is slow compared 
to other compilers / interpreters.  Joseph is right, it may be faster if 
its optimized for speed but thats something we'll need to test.  Now 
about the speed of DeepSpace.  The geometric data of the virtual objects 
must be recalculated in real time.  This is what gives the object the 
effect of "moving" through space.  Even if the arithmetic operations are 
up to speed, this must be done in a loop.  So it stands to reason that 
the speed of a loop is important.

Like you said the DrawingArea is slow due to the caching .  How do you 
propose that I draw to the screen without it?  I asked about this in 
other emails to you and told me that I'm stuck using it.  Drivers will 
have some to do with the speed.  Very little from user to user though 
due to the fact that I'm not using hardware acceleration.

If Gambas supported threads then I could move the arithmetic operations 
and rendering operations into their own threads.  This way operations 
would'nt be linear like they are now, and could be done in tandem.  This 
would yield a serious improvement in speed.

My conclusion is that Gambas needs work on its speed and that Threads 
would be nice.

--
Michael