I think you're missing a lot of data by concentrating on cold starts, a situation that is very much not representative of the general cases.
The speed gain for non-cold starts is much more interesting, IMHO. Also, could you do tests with Py 3.1 vs 3.2? Baring differences in hardware that should be in your advantage (if I'm reading this right), there's no good reason to explain the difference in timings between you and Ton. If there's an big measurable slowdown in 3.2, it might be worth it to log a bug upstream. I think there's some really nice numbers we could squeeze out of this with a bit more rigorous method (different OS, stable conditions, same py version, ...). Good work digging into this, even though the payoff might appear small. Martin --- On Sun, 2/27/11, Campbell Barton <ideasma...@gmail.com> wrote: > From: Campbell Barton <ideasma...@gmail.com> > Subject: Re: [Bf-committers] Blender Startup Time > To: "bf-blender developers" <bf-committers@blender.org> > Received: Sunday, February 27, 2011, 8:23 AM > Some more tests and found lazy > loading of modules in other areas, > gives good speedup on cold start. > > Times don't compare to last tests because I disabled some > options > (BGE, FFMPEG etc). > I did lazy importing of modules: > traceback, shutil, time, math and pydoc > I also removed 'collections' import as well as > netrender. * > > Results for "time ./blender -b" after flushing disk cache, > Normal: 8.923 sec > Lazy Loading: 4.647s > > * note, removing collections import means we would need to > use a > different ordered dict metaclass, I'm not worried about > this since we > don't use many of the OrderedDict features, we could have a > cut down > version. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers