fetchClassOf & commonSend?

Doug Way dway at riskmetrics.com
Thu Dec 13 00:42:14 UTC 2001


Scott A Crosby wrote:
> 
> On Mon, 10 Dec 2001, John M McIntosh wrote:
> 
> > At 3:02 AM -0400 10/5/01, Scott A Crosby wrote:
> > >Date: Sat, 22 Sep 2001 12:40:00 -0700
> > >From: Andreas Raab <Andreas.Raab at gmx.de>
> > >Reply-To: squeak-dev at lists.squeakfoundation.org
> > >To: squeak-dev at lists.squeakfoundation.org
> > >Subject: RE: Performance profiling results...
> > >
> > >Scott,
> > >
> > >Interesting results!
> > >
> >
> > Ah, did we ever fix this? and get it into the update stream?
> 
> No... So far, *nothing* I've done has gotten into the update stream.

(Speaking as one of the harvesters)  I think that might be due to the nature of proposing performance improvements which aren't simple changes (e.g. involving changes to the interpreter or rehashing existing collections)... it's a bit more work to test and incorporate those types of changes.  And sometimes it's good to let the discussion settle down before considering incorporating something that generates lots of discussion. :)

Also, the current group of harvesters hasn't really been reviewing interpreter changes (it's outside my area of expertise anyway), so those changes are mostly up to someone at Squeak Central to take the initiative to incorporate.  (But that may change in the future.)

And in the last month or so we've been mostly looking at fixes (as opposed to enhancements or performance improvements) until 3.2 is finished.

But I think the stuff you're working on is definitely worthwhile, and some of it will probably get into the update stream at some point.  (e.g., I was going to look at maybe adding your fine-grained MesssageTally changes as a preference.)

On another note, with some of your proposals, it would be useful to have some code snippets with before/after timing results, to see what exactly is being improved.  (sometimes it's hard to keep track in a lengthy discussion)  For example, for the identityHash changes, some "Time millisecondsToRun: [...]" before & after timings of, say, adding elements to a Set of 500, or 50000.  Or with an IdentitySet.  Or using select:.  Etc.  Whatever best shows the improvement.

Just some thoughts,

- Doug Way
  dway at riskmetrics.com



> > Doing benchmarks and sure enough my interp.c calls out 293 million
> > times to fetchClassOf for the test I'm doing...
> 
> Yep, the ONE place you do want that inlined, its not being inlined..
> Though, may I suggest just using my improved cache (30% faster), I have
> this fix already included in that changeset.
> 
> >
> > Also 161 million calls to ioMSecs or 272,923 calls per second! but I
> > need to investigate that more...
> 
> Yep, I reported this over 2 months ago.. Its because primitiveResponse()
> checks the clock before and after every primitive to determine whether it
> ran over the timer interrupt.
> 
> Workaround by:
> 
> #define ITIMER
> 
> in sqXwindow.c (I send an email out yesterday to the list reminding
> everyone of my work, including this.)
> 
> >
> > Mind what I'm seeing was 15% of the time in the mach-o was taken to
> > calculate macho-carbon milliseconds. Using gettimeofday is much more
> > efficient. 5%+  was taken in pthreads, that's fixed too.
> >
> 
> I saw about 5% wastage, but I only had 40k invocations/second. You're
> getting a *lot* more.
> 
> Scott




More information about the Squeak-dev mailing list