Trailers speedup (Re: [squeak-dev] The Trunk: Kernel-ul.362.mcz)
siguctua at gmail.com
Mon Jan 4 08:12:07 UTC 2010
2010/1/4 Levente Uzonyi <leves at elte.hu>:
> On Mon, 4 Jan 2010, Igor Stasenko wrote:
>> They make a difference.
>> Actually, when coding the stuff, i was more concerned about #endPC
>> than anything else,
>> since now it will be calculated much slower, because trailer decoding
>> the data , even if its not used by sender which might be interested in
>> getting #endPC only.
>> To optimize this, i though that maybe it worth to decode data lazily,
>> while in #method: , calculate only size field.
>> But i'm not sure, if it worth spending time optimizing it, since i'm
>> not measured the impact.
>> My nitpick was about workarounds in using #perform: with pregenerated
>> selectors. Other changes, which
>> focused on avoiding generating temporary trailer instance is
>> definitely worth doing.
> I didn't look at the code in detail until now and I think it would be better
> to use subclasses for dispatching. This means removing the kind variable and
> every existing trailerKind would have it's own subclass. The subclasses
> would have 3 responsibilites #kindAsByte (returns a constant) #encode and
> #decode (implement the kind specific encoding/decoding). The class side
> #trailerKinds method could be generated based on the #kindAsByte
> implementations. A single method could be used for dispatching like:
> CompiledMethodTrailer class >> for: method
> | flagByte |
> flagByte := method at: method size.
> ^(self trailerKinds at: flagByte >> 2 + 1) new
> method: method;
> Where trailerKinds returns an Array with the subclasses.
> What do you think?
This is much better, its however spawns a number of subclasses. So if
you think it worth more attention, then do it.
One of positive moments, that if you make a trailer kinds to be
classvar, and change #kindAsByte appropriately,
then we could allow an easy plug-in and plug-out interface for new
trailer kinds by external package, without need of reserving a
If you gonna to implement that, do not forget to create an interface
for uninstalling the trailer kind
and in #uninstallTrailer:, replace it with undefined trailer for all
methods which currently using this trailer kind.
P.S. And if you gonna do that, please make sure to provide changes for
adopting them in both trunk and Pharo ;)
P.P.S. And try to not introduce any of #isKindOf: or #isXXX patterns :)
>> Best regards,
>> Igor Stasenko AKA sig.
Igor Stasenko AKA sig.
More information about the Squeak-dev