Kturtle 0.8beta performance

[Grigoris Markakis]

I executed the following code in KTurtle 0.6 (KDE 3) and the execution completed after 25 seconds:

learn tree step, length [
  if step > 0 [
    forward length
    turnleft 75
    tree step-1, 0.7*length
    turnright 115
    tree step-1, 0.7*length
    turnleft 40
   backward length
  ]
]

reset
canvassize 600, 600
go 300, 450

tree 15,150


I tried the same code (with the necessary changes) in KTurtle 0.8 beta (KDE 4) and takes hours with CPU usage over 40%
Is this acceptable ?

Here is the code:

learn tree $step, $length {
  if $step > 0 {
    forward $length
    turnleft 75
    tree $step-1, 0.7*$length
    turnright 115
    tree $step-1, 0.7*$length
    turnleft 40
   backward $length
  }
}

reset
canvassize 600, 600
go 300, 450

tree 15,150

--
Grigoris Markakis
Computer Engineer

[Andre Krause]

first, yes, kturtle is slow, but it is educational software. the emphasis is on learning. therefore kturtle 0.8 has that great step-wise yellow highlighting of the current position in the code while executing.

i found, that if you close the code editor window, kturtle 0.8 runs much faster.

can you try again with closed code window?

but if you need high performance, you should consider using fsm logo:

http://fmslogo.sourceforge.net/

though its much more difficult to use for beginners (because of no obvious "code editor window" and a little strange gui)

nonetheless, i would appreciate higher execution speed for kturtle, too. the "curly" demo is quite slow, even with closed code editor window. 

[Grigoris Markakis]

I closed the code editor and the inspector, but it is still slow.
KTurtle 0.6 was fast enough, maybe 0.8 can work on that.
I like the newer version and the speed isn't problem for my lesson, but if someone can fix it, it would be nice !

Thanks for the advice !

--
Grigoris Markakis
Computer Engineer

[Niels Slot]

I've been aware of the speed issues with KTurtle since I started working on the KDE4 version of KTurtle (back in December 2006). I've tried looking in to it a couple of times but never found a solution. I think the performance problem here is QGraphicsView. Each line the turtle draws becomes a QGraphicsLineItem. With some scripts this means that you get a lot of QGraphicsLineItem objects in a very short time. But this is just only a theory. I think we need someone with more knowledge of Qt and QGraphicsView to have a look at this.

As an alternative I could investigate porting the current QGraphicsView based approach to a lighter QWidget approach. (Just use the plain painting API of Qt.)

Niels

2008/10/12 Grigoris Markakis <grigoris...@gmail.com>

[cies]

there are several issues:

- the interpreter is now statefull this is internal bla-bla but is
makes the code more beautiful (the earlier kde3-kurtle interpreter
might been faster due to statelessness, but it was sure not that
pretty code).. a solution might be: put the interpreting in a thread,
this bring a whole new dimension of possible errors to the codebase,
but it might work.

- qgraphicsview, yes, svg is slower than pixel-shizzle. but it
prints/zooms nicer.

- highlighting during execution, a major feature to make kturtle a
learning tool, but also slowing down the execution a bit. maybe one
run mode can turn this thing off (this will cost still at least one
operation per highlighting signal, namely the if-statement, but that
cannot be noticable)

- other changes to the interpreter.. i dont know all i changed to it
but for sure there might be some things that can be done in a faster,
more efficient, manner.

bottom line for me, as already mentioned: speed is not the 1st priority. sorry.
i'd love to oneday rewrite the whole interpreter again in something
fast, threaded, clean, and more 'generated' (the parser is now
hand-written, no yacc)

_c.