Hacker News Reader

Comment by tintin | Hacker News Reader

You are wrong.

Everytime I start Blender (3D content creation suite) I'm blown away by the time it takes to start. Less than 2 seconds! Ready to use!

Do I call Blender a complicates program? Yes I do. The feature list can compete with the one of 3ds Max.

View on HN

I think it's unfair for you to call him wrong, what's wrong with what he said in the context of what he was saying?

I remember Blender loading fast as well. But are you sure every single feature of the program is available as soon as the GUI is displayed? Because I wouldn't be surprised if there's some lazy loading going on. Maybe some things finish loading in the background so they are not available right away or maybe some things are loaded on demand to spread out the loading time.

But are you sure every single feature of the program is available as soon as the GUI is displayed?

I hope not.

Of course Blender is lazy loading as you like to call it. Why load features the user is not using atm? The base of the program is just way better than lets say Photoshop.

Ever checked an online Photo editor? (http://pixlr.com/editor/ for example after a quick Google). Open the page and there it is: your interface ready to use.

To clarify, "lazy" isn't a pejorative in this case. It's just the technical term for deferring work until it needs to be done. "Eager" would be the term for doing everything right away.

Loading on demand is a vast improvement over loading everything up front, though. Loading on demand means you never pay the price for functionality that isn't used, and if your load time is divided into little pieces, it's far more likely to slip into spaces where the user is otherwise preoccupied, thus becoming essentially free. Lazy loading is a way to truly reduce loading time, not just a way to hide it as you seem to imply.

Well, lazy loading is a way to hide loading time. But I didn't mean that lazy loading is bad since I think it is rather underutilized in desktop applications. Taking Photoshop as an example, I would explore the means to get the basic app up and running providing basic tools then load the rest in the background not waiting for demand. Loading on demand is nice as long as it can be done quickly. There's nothing worse than having the app loaded, click on a menu item, and then have to wait for that feature to load.

I think loading on demand is a vast improvement in some instances. For something like Photoshop, I'd gladly pay the initial 10 seconds for a more responsive interface. Photoshop is already slow, imagine dynamically loading resources on top of its usual sluggishness.

I remember one of the versions of PhotoShop (perhaps it was CS2) no longer loaded fonts at startup and the launch speed improved. But then the first time you select the font drop-down you had to wait around 5 seconds.

So I guess the launch was faster but waiting for the fonts to load was annoying when I was in the middle of working. During the app startup I'm probably spacing out for a few seconds while the app launches.

I see similar things in other apps. One that comes to mind at the moment is Eclipse where there are certain menu items when you drag over them the app freezes for a second. I always curse myself when I accidentally roll over one of those.

Particular parts of the app that require a lot of disk access may have a bit of a performance hit and so it makes sense to lazy load them, but it is a trade-off and sometimes I'd rather just wait a few moments at launch instead of getting killed by a thousand cuts while working.

That is exactly the debate between loading upfront and loading on demand. Either way, you'll have to load resources. But it seems sometimes people like to ignore that fact. The key is finding what works best for the particular application at hand. Personally, for something like Photoshop I'd rather have the long upfront load as opposed to hitches when loading a feature on demand.

Which, out of curiosity I timed it, the "long" loading time for Photoshop CS5 on my machine is less than six seconds. It think I can wait that long.

> That is exactly the debate between loading upfront and loading on demand. Either way, you'll have to load resources.

Everybody seems to be missing the third way: load in the background as the user can already work.

Take those fonts, you could spend 5s loading them during the splashscreen making the user wait, you could spend 5s loading them when first requested making the user wait again. Or you could load them after the program has started, in the background.

Will the user go from "empty document" to opening the fonts dropdown in under 5s? Pretty damn unlikely, and if he does he'll wait for the remainder of the load. In either case, he just "won" 5s.

Problem then is that as soon as I start using the program I might say want to load some data into it which is on the same drive as the program itself.

If I don't have an SSD my drive head is going to be spinning around like crazy trying to load resources from different parts of the disk at once which is going to give me slower overall performance. If you do have an SSD then it's likely fast enough either way.

Eclipse really should be loading those in the background while you are working.

> I remember Blender loading fast as well. But are you sure every single feature of the program is available as soon as the GUI is displayed?

This is exactly the point made in the article...

Blender's startup speed astounds me when compared to just about everything else I use. It starts faster than Vim half the time!

Reply on news.ycombinator.com