Performance gains at the cost of your own components

by Michael S. Kaplan, published on 2005/03/12 02:23 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/03/12/394420.aspx


Raymond Chen posted yesterday about Performance gains at the cost of other components. I thought I would give a slightly different take on the problem, from days as a sorta Access hero several years ago....

You see, I owned the wizards, which was a funny place to be. Especially when Access 97 was going on. They did not have a code name of "Mach 5" for nothing; performance was a big deal.

A lot of the tricks that Raymond referred to were not an option -- since not everyboy ran Access. They could not do as much beforehand or people would notice and make them yank stuff back into their product.

But they could delay load stuff. By putting off the price as long as possible, users would get the benefit of perceived faster performance.

Unfortunately, all of the ways people did this would hurt wizards. The code that would delay load VBA and the expression service just meant that if you started Access and then started a wizard that Access would look faster and the wizard would look slower....

Sucked for me a bit, but mostly a good thing for customers. Except for the ones who wanted to use wizards....

But wizards had other tricks that worked well for them. For reasons surpassing understanding, people feel that a delay for a wizard to load is unacceptable, because the wizard has not done anything yet. Why pay the price if no action has been taken? But if there is a delay after you push the "Finish" button on the wizard then thats okay -- the wizard is now doing something at the user's request.

The fact that code has to run in both cases is not something that all people are willing to consider. I remember one wizard that we actually had to find more for it to do -- we had to slow it down a bit since it was finishing so fast that users would not believe the wizard had done the job! But if that same wizard were to load any slower, the same people would have yelled bloody murder. This slowing down of the final step is a trick I have needed several times since then on various projects, and to this day the lightning fast init phase and the task phase that is just slow enlough for users to trust that the job go done is a less sinsister model that has served me well....


no comments

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2006/12/06 Hurry up and make it slower, already!

2006/05/12 Don't use lstrcmp if you don't need it

go to newer or older post, or back to index or month or day