slate gui slowness needs fixing before proceeding

[Nick Forde]

Brian Rice wrote:
> On Jun 12, 2006, at 5:27 AM, Nick Forde wrote:
> 
>> Tony Garnock-Jones wrote:
>>
>>> Timmy Douglas wrote:
>>>
>>>> processed by the ui fairly quickly (1 sec between typed characters
>>>> showing up) compared to the delay before the events registered (like
>>>> 2-10 sec after the first keypress). But if you try  inspector.slate and
>>>> try to drag the inspector windows you will go crazy. I guess mouse
>>>> motion events really drag it down or something along those lines.
>>>
>>> It sounds like there's something rotten in the interface to SDL,  rather
>>> than basic slowness of Slate... well, I'd be surprised if it was  Slate
>>> since I've always been pleasantly surprised at the speed of the  system
>>> in general. Perhaps there's something sub-par in the polling logic?
>>
>>
>> I haven't tried the SDL interface but you can get a very rough idea
>> of the basic VM performance by running 'make benchmark' and
>> comparing the results to those at: http://shootout.alioth.debian.org/
>> Last time I tried this the results were unfortunately not good :-(
> 
> 
> *ahem* Just to be pedantic, that's not the VM's performance, that's  the 
> VM+image's performance. There are a lot of message sends that  happen 
> for basic control-flow operations, for example, or even for  just 
> executing a non-literal (argument to a method) block.

For most of the benchmarks that is indeed true. However, I added an extra
primitive to the VM to trace PSInterpreter_[re]sendMessage*() calls only
during the body of the benchmarks. I found that in some of the simple tight
loop tests the number of message sends wasn't excessive but most of the
execution time was in their dispatch. These benchmarks still fared poorly
when compared to the shootout results.

> That said, the VM design is rather naive and could be much better,  but 
> not by the order of magnitude that the shootout benchmarks are.  The 
> performance problem we have relates to the Strongtalk design - we  just 
> have no inlining compiler to rely on.

I think you're right and agree that this is where the biggest
performance gains can be had.

Nick.