[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 |
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
- Re: StepTalk - speed,
Stefan Urbanek <=