Re: StepTalk - speed

[Stefan Urbanek]

Hi,

On 2003-11-09 23:57:34 +0100 Alexander V. Diemand 
<Alexander.Diemand@etu.unil.ch> wrote:

> Hi Stefan
>
> I am still working on StepTalk and enjoy scripting with it.
> But, it seems there is a huge bottleneck causing StepTalk to process at
> slow speed: the address of the selector is evaluated at time of bytecode
> interpretation (-sendSelectorAtIndex:withArgCount: in
> STByteCodeInterpreter.m). Why isn't it possible to have all this done at
> compile time in STCompiler? Was this a critical design decision in
> StepTalk?

The reason for such selector lookup is kind of "security" that was planned in 
StepTalk. Idea behind this was to be able to block some selectors and to translate symbolic 
selectors (like = < > + - ...). Definitely, this part is really a bottleneck, as you have 
said. I know about it, however never done anything with that, because I did not needed much 
speed, yet.

> I am working with scripts that do iterate over hundreds of objects and
> call subroutines in SmallTalk with them and a number of calls to classes
> in a linked library. StepTalk is far too slow to handle complex scripts,
> so I am forced to implement them in Objective-C.

I understand...

> I assume that having the evaluation of the selector at compile time,
> freeze it and then just "believe" it at bytecode interpretation would
> lead to a dramatic speed-up.

What do you mean? Like get the proper selector from runtime at compile time? If 
that, then it can be done, however, very carefully. Compiled scritps can be 
transferred between processes and they do not have to work. But this needs to 
be more elaborated. Note, that you do not know actual selector for symbolic 
selector because you do not know a receiver.

Maybe we should agree on some specified symbolic-standard selector map?

> Have you (or somebody else) run some test on this? Where do you think is
> the best way to hook into the system and make the necessary changes?

Well, whole selector lookup mechanism needs to be rewritten. Currently the 
selector lookup is done in STEnvironment.

- (NSString  *)translateSelector:(NSString *)aString forReceiver:(id)anObject;

And this is really slow. 'It just works'.

What can be done is (for example):

- use SEL right as the literal value in the STCompiledCode object
- use unified map for symbolic selectors
- remove the mentioned method and use some fast '-isSelectorAllowed:(SEL)sel 
forReceiver:(id)target instead. (this lookup can be disabled when 
'isFullScriptingEnabled' is YES)

What do you, and the others, think?

Stefan Urbanek

p.s.: Because I am now in a time stress, is there anyone who wishes to help a 
bit?
--
First they ignore you, then they laugh at you, then they fight you, then you 
win.
- Mahatma Gandhi