Namespaces & performance?
Locked
 
|
Hi,
I have a question about namespaces. I have a method: test OrderedCollection yourself. When I execute it a lot of times it runs very fast (it doesn't do anything special either). I have another method: test2 Core.OrderedCollection yourself. When I execute it a lot of times, it runs a lot slower than #test. It seems that most of the time is spent in looking up the class in a namespace, or getting it from a cache in a LiteralBindingReference as you can see from the timeprofiler's profile below: 100.0 GeneralBindingReference>>value 59.2 primitives 40.8 GeneralBindingReference>>binding 40.8 GeneralBindingReference>>bindingOrNil 40.8 GeneralBindingReference>>bindingOrNilWithProtection: 40.8 GeneralBindingReference>>resolveWithProtection:orDo: 12.3 ProcessEnvironment>>bindingHandler 12.3 ProcessEnvironment>>bindingHandler 12.3 Process>>environment 12.2 primitives 4.0 ResolvedDeferredBinding>>value When I inspect the the CompiledMethod #test, it contains a literal: (ResolvedDeferredConstant key: #OrderedCollection) When I inspect the CompiledMethod #test2, it contains a LiteralBindingReference: #{Core.OrderedCollection} Why isn't there a ResolverDeferredConstant for the #test2 method? Doesn't the compiler know the class when seeing Core.OrderedCollection? Is there a way around having this performance drop if you don't want fall back on importing namespaces/classes? Or is importing the way to go when you start using namespaces? Thanks, Mark |
Re: Namespaces & performance?
|
|
Mark Plas wrote:
> Hi, > > I have a question about namespaces. > > I have a method: > > test > > OrderedCollection yourself. > > When I execute it a lot of times it runs very fast (it doesn't do > anything special either). > > I have another method: > > test2 > > Core.OrderedCollection yourself. > > When I execute it a lot of times, it runs a lot slower than #test. methods -the slowness gets optimized away. Essentially Core.OrderedCollection gets resolved and cached - but if you do it inside a doIt, then it'll always be a new Core.OrderedCollection binding, so the cache will not have any affect. Cheers, Michael |
|
|
In reply to this post by Mark Plas
Hi Michael,
I did the experiment with two methods, not with doits. The value gets cached but it's still a lot slower than not putting the namespace in front of the class name. Is there a reason why there is a LiteralBindingReference instead of a ResolverDeferredConstant? I would think the compiler knows the class at compilation time? Mark -----Original Message----- From: Michael Lucas-Smith [mailto:[hidden email]] Sent: donderdag 8 november 2007 13:11 To: Mark Plas Cc: [hidden email] Subject: Re: Namespaces & performance? Mark Plas wrote: > Hi, > > I have a question about namespaces. > > I have a method: > > test > > OrderedCollection yourself. > > When I execute it a lot of times it runs very fast (it doesn't do > anything special either). > > I have another method: > > test2 > > Core.OrderedCollection yourself. > > When I execute it a lot of times, it runs a lot slower than #test. methods -the slowness gets optimized away. Essentially Core.OrderedCollection gets resolved and cached - but if you do it inside a doIt, then it'll always be a new Core.OrderedCollection binding, so the cache will not have any affect. Cheers, Michael |
|
|
In reply to this post by Michael Lucas-Smith-2
I find even in a method its 5x slower -- and I have been hit with this
to the point of doing my own caching in a few places. Michael Lucas-Smith wrote: > Mark Plas wrote: >> Hi, >> >> I have a question about namespaces. >> >> I have a method: >> >> test >> >> OrderedCollection yourself. >> >> When I execute it a lot of times it runs very fast (it doesn't do >> anything special either). >> >> I have another method: >> >> test2 >> >> Core.OrderedCollection yourself. >> >> When I execute it a lot of times, it runs a lot slower than #test. > This is a somewhat misleading test. If you put both pieces of code in > to methods -the slowness gets optimized away. Essentially > Core.OrderedCollection gets resolved and cached - but if you do it > inside a doIt, then it'll always be a new Core.OrderedCollection > binding, so the cache will not have any affect. > > Cheers, > Michael > -- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 sip:[hidden email] Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP |
Re: Namespaces & performance?
|
|
In reply to this post by Mark Plas
Mark Plas wrote:
> Hi Michael, > > I did the experiment with two methods, not with doits. The value gets > cached but it's still a lot slower than not putting the namespace in > front of the class name. > That'll teach me to reply at 7am :) |
|
|
In reply to this post by Mark Plas
Dear Mark,
> Or is importing the way to go > when you start using namespaces? Avoiding explicit namespace dotted references is a rule I was taught and which I follow. I believe it helps both performance and (slightly) code clarity and quality. I recommend it. I try only to use explicit references when I am in any case recovering the class from a reference (e.g. windowSpec methods) and (very rarely) when minor changes to someone else's code would be far more intrusive if I did not. As well as importing: - I expect you know DefaultPackageNamespaces, useful when avoiding dotted references in extension methods. - Recently, I've ben publishing my first-find namespace work in Porting-NameSpaces (in the OR); so called because I expect their main use will be when porting from single-namespace dialects (and may be temporary, just during the period when code synchronisation is more important than VW customisation). If (and only if) one reason for your being shy of import chains was concern that they may produce name collisions then it may be of use. Be aware it's experimental and only modestly tested. Package and class have long comments (like all my stuff :-)). Yours faithfully Niall Ross Mark Plas wrote: >Hi, > >I have a question about namespaces. > >I have a method: > >test > > OrderedCollection yourself. > >When I execute it a lot of times it runs very fast (it doesn't do >anything special either). > >I have another method: > >test2 > > Core.OrderedCollection yourself. > >When I execute it a lot of times, it runs a lot slower than #test. It >seems that most of the time is spent in looking up the class in a >namespace, or getting it from a cache in a LiteralBindingReference as >you can see from the timeprofiler's profile below: > > 100.0 GeneralBindingReference>>value > 59.2 primitives > 40.8 GeneralBindingReference>>binding > 40.8 GeneralBindingReference>>bindingOrNil > 40.8 GeneralBindingReference>>bindingOrNilWithProtection: > 40.8 GeneralBindingReference>>resolveWithProtection:orDo: > 12.3 ProcessEnvironment>>bindingHandler > 12.3 ProcessEnvironment>>bindingHandler > 12.3 Process>>environment > 12.2 primitives > 4.0 ResolvedDeferredBinding>>value > >When I inspect the the CompiledMethod #test, it contains a literal: > > (ResolvedDeferredConstant key: #OrderedCollection) > >When I inspect the CompiledMethod #test2, it contains a >LiteralBindingReference: > > #{Core.OrderedCollection} > >Why isn't there a ResolverDeferredConstant for the #test2 method? >Doesn't the compiler know the class when seeing Core.OrderedCollection? > >Is there a way around having this performance drop if you don't want >fall back on importing namespaces/classes? Or is importing the way to go >when you start using namespaces? > >Thanks, >Mark > > > > > |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |