Hi Marcel,

The current implementation of CodeHolder >> 
#formattedLabel:forSelector:inClass: breaks TimeProfileBrowser, which 
passes nil as the class argument.

On Tue, 13 Aug 2019, Marcel Taeumel wrote:

> Okay, I addad that in Tools-mt.871. With the speed-up from Kernel-mt.1255, we get those results:
> 
> | msgs |
> msgs := Morph selectors.
> 
> [msgs do: [:sel | (Morph compiledMethodAt: sel ifAbsent: [#booh]) isDeprecated]] bench 
> '2,180 per second. 458 microseconds per run.'

With some inlining, block elimination, and the use of the unicity 
property, the performance can be doubled by rewriting CompiledMethod >> 
#isDeprecated to

 	| literal |
 	1 to: self numLiterals do: [:index |
 		((literal := self literalAt: index) == #deprecated: or: [ literal == #deprecated ])
 			ifTrue: [ ^true ] ].
 	^ false

> 
> [msgs do: [:sel | Morph isDeprecated or: [(Morph compiledMethodAt: sel ifAbsent: [#booh]) isDeprecated]]] bench 
> '1,670 per second. 597 microseconds per run.'
> 
> Morph has 1353 selectors and that formatting is cached in tools. I think we're good. Tim, what about RasPi performance? :-) Bert, what about SqueakJS performance? ;-)

I used to think SqueakJS was 2-3 magnitudes slower than Spur, but 
sometimes it's 4 magnitudes.
By implementing the #hashMultiply primitive, and regenerating 
MiscPrimitivePlugin's primitives from the Spur branch, I'm sure many 
things would become quicker.

Levente

> 
> Best,
> Marcel
>
>       Am 13.08.2019 09:10:14 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
>
>       Hi Christoph.
> > Just to be sure: You would like to decorate each single method of a class such as HtmlFileStream with the deprecated attribute?
> 
> That's not what I meant. Just those selected deprecations in non-deprecated classes. You are referring to deprecated classes as such? That's right. We should change CodeHolder >> #formattedLabel:forSelector:inClass: to always treat methods in deprecated classes as deprecated. Not just if the selector is
> #Definition. :-)
> 
> Best,
> Marcel
>
>       Am 12.08.2019 19:35:35 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
>
>       Hi Marcel,
> 
>
>       > > 1. It's not really nice that CompiledMethod>>#isDeprecated is styled or even
>       > > detected as deprecated :)
>       > 
>       > Well, for a single case, I did not want to add an extra check that is usually false anyway. Want it to be as fast as possible.
> 
> Good point :)
> 
> > Well, no. If those methods are missing their #deprcated explanation, take it as a chance to really deprecate those methods:
> > 
> > (1) double-check that there are no senders
> > (2) add "self deprecated:"
> > (3) maybe rewrite them to use the new interface
> > 
> > There is so much clean-up to do. ;-)
> 
> Just to be sure: You would like to decorate each single method of a class such as HtmlFileStream with the deprecated attribute?
> 
> Best, Christoph
> 
> __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
> Gesendet: Montag, 12. August 2019 19:19:23
> An: John Pfersich via Squeak-dev
> Betreff: Re: [squeak-dev] The Inbox: Tools-mt.856.mcz  
> Hi Christoph.
> > 1. It's not really nice that CompiledMethod>>#isDeprecated is styled or even
> > detected as deprecated :)
> 
> Well, for a single case, I did not want to add an extra check that is usually false anyway. Want it to be as fast as possible.
> 
> > 2. Would it be worth a thought to also style classes and all their methods
> > as deprecated, which are in *Deprecated* categories? For example, when
> > browsing through a MessageTrace, I think it could be helpful to see which
> > methods are no longer relevant - for the same reason as Patrick mentioned.
> 
> Well, no. If those methods are missing their #deprcated explanation, take it as a chance to really deprecate those methods:
> 
> (1) double-check that there are no senders
> (2) add "self deprecated:"
> (3) maybe rewrite them to use the new interface
> 
> There is so much clean-up to do. ;-)
> 
> Best,
> Marcel
>
>       Am 09.08.2019 23:24:01 schrieb Christoph Thiede <christoph.thiede at student.hpi.uni-potsdam.de>:
>
>       Hi, great idea! Two thoughts:
>
>       1. It's not really nice that CompiledMethod>>#isDeprecated is styled or even
>       detected as deprecated :)
>
>       2. Would it be worth a thought to also style classes and all their methods
>       as deprecated, which are in *Deprecated* categories? For example, when
>       browsing through a MessageTrace, I think it could be helpful to see which
>       methods are no longer relevant - for the same reason as Patrick mentioned.
>
>       Best,
>       Christoph
> 
> 
>
>       --
>       Sent from: http://forum.world.st/Squeak-Dev-f45488.html
> 
> 
>