[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: StepTalk - speed

From: Stefan Urbanek
Subject: Re: StepTalk - speed
Date: Mon, 10 Nov 2003 14:47:03 +0100


On 2003-11-09 23:57:34 +0100 Alexander V. Diemand <address@hidden> 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

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 
First they ignore you, then they laugh at you, then they fight you, then you 
- Mahatma Gandhi

reply via email to

[Prev in Thread] Current Thread [Next in Thread]