[Bf-committers] Blender Startup Time
ideasman42 at gmail.com
Sat Feb 26 04:12:46 CET 2011
@Carsten, others on IRC said this too - that we are doing ok compared
to others and should not worry about startup times.
The thing is, since python was added we have not made _any_ effort to
make blender efficient for startup, importing modules without worrying
of the side-effect or trying to minimize what is loaded.
@GSR, by function body removed, this means every function had its body
replaced with 'pass'
I think most of this problem can be fixed by doing lazy-importing.
Where a scripts will only register its classes on startup but not
actually load the majority of the code which can be stored in a
submodule and imported as needed.
I've already done this for OBJ/FBX/PLY/3DS io scripts and found it a
simple change to make and doesn't make the scripts hard to
Looking at netrender loading, it indirectly calls 3050 open(), stat()
and fstat() combine.
strace ./blender --debug > out.txt
# isolate netrender startup
cat out.txt "^open(\|^stat(\|^fstat("
Compare to FBX which does lazy loading, it does only 35 open/stat/fstat's.
Granted, a lot of this is out of control of netrender since pythons
internals are searching all over the hard drive for files,
nevertheless lazy loading helps a to avoid the problem.
On Fri, Feb 25, 2011 at 7:38 PM, GSR <gsr.b3d at infernal-iceberg.com> wrote:
> ideasman42 at gmail.com (2011-02-25 at 1300.36 +0000):
>> One thing I found was disk speed on a 'cold start' to be the major bottleneck,
>> Does anyone know some way we could asynchronously cache certain files
>> on load so when they are needed it wont lag so much?
> When it says "function body removed", does that mean all in a single
> file but no real useful code? Or in other words, reading less files
> cuts time to 36-44% and reading same number of files, but smaller in
> size, to 25-31%. Also reading zip of normal files is just a bit slower
> than reading the combined version. Do you see a trend?
> It is not exactly disk speed, more like disk seeks, which is basically
> the issue all modern software is hitting as nobody realizes CPUs have
> gone a lot faster, RAM a bit faster, but disks are more or less stuck
> where they were years ago (8ms seeks, ~100 or less disk ops per
> second), specially if reading non contiguous sectors (ignore SSD for
> now). Add more files in the form of config, icons, thumbnails, etc and
> the performance sucks. I remember someone saying that disk access is
> like tape access was, rewind kills you.
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers