[Bf-committers] Blender Startup Time

[Campbell Barton]

@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'

class Panel(...):
    def draw(...):
        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
read/maintain.

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("

Full output
http://www.pasteall.org/19495/c

Compare to FBX which does lazy loading, it does only 35 open/stat/fstat's.
http://www.pasteall.org/19496/c

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.

- Campbell

On Fri, Feb 25, 2011 at 7:38 PM, GSR <gsr.b3d at infernal-iceberg.com> wrote:
> Hi,
> 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.
>
> GSR
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell