@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....@infernal-iceberg.com> wrote: > Hi, > ideasma...@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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers