Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Would it make sense to put all used selectors in the literal array? #5634
Right now we do not put all the selectors in the literals that are in "Smalltalk specialObjectsArray at: 24":
"#(#+ 1 #- 1 #< 1 #> 1 #'<=' 1 #'>=' 1 #= 1 #'~=' 1 #* 1 #/ 1 #'\' 1 #@ 1 #bitShift: 1 #'//' 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 #nextPut: 1 #atEnd 0 #'==' 1 #class 0 #'~~' 1 #value 0 #value: 1 #do: 1 #new 0 #new: 1 #x 0 #y 0)"
This is done to save space. Which is understandable for a System designed in 1978, it even makes sense in 2005. But today?
I propose we go to the bank and sell some "Mores law" stock and invest it in simplicity: add all these selectors when we compile method to the literal frame, if they are send in the method.
I wouldn't do anything unless we add tests about this.
Is this speed really relevant? I don't think so... Do you have measurements?
I have the feeling that depending on the literal frame of methods is brittle and breaks always at the end. Particularly, how does this work with bytecode rewrites where the original sourcecode
Yes, you are right that it would just be a small improvement and not solve to problem for real. What we need (as you imply) is to make the distinction of "Language Model" and "Execution Model" of methods explicit: Maybe we need "Method" and "CompiledMethod", in some way... ?
The VM would deal with CompiledMethod, the IDE with Method. MetaLinks would change CompiledMethod, but not Method, and so on.
Don't take me wrong. What I mean is that I'd like to backup assertions like "the system will get faster" with a measurement
And avoid doing such a change (that will maybe impact people using senders :)) without a proper test.
We agree :)