Welcome to MSDN Blogs Sign in | Join | Help

Performance gains at the cost of other components

In the operating systems group, we have to take a holistic view of performance. The goal is to get the entire system running faster, balancing applications against each other for the greater good.

Applications, on the other hand, tend to have a selfish view of performance: "I will do everything possible to make myself run faster. The impact on the rest of the system is not my concern."

Some applications will put themselves into the Startup group so that they will load faster. This isn't really making the system run any faster; it's just shifting the accounting. By shoving some of the application startup cost into operating system startup, the amount of time between the user double-clicking the application icon and the application being ready to run has been reduced. But the total amount of time hasn't changed.

For example, consider the following time diagram. The "*" marks the point at which the user turns on the computer, the "+" marks the point at which Explorer is ready and the user double-clicks the application icon, and the "!" marks the point at which the application is ready.

* OS Startup + Application Startup !

The application developers then say, "Gosh, that pink 'Application Startup' section is awfully big. What can we do to make it smaller? I know, let's break our application startup into two pieces...

* OS Startup + Application Startup 1 Application Startup 2 !

"... and put part of it in the Startup group.

* OS Startup Application Startup 1 + Application Startup 2 !

"Wow, look, the size of the pink bar (which represents how long it takes for our application to get ready after the user double-clicks the icon) is much shorter now!"

The team then puts this new shorter value in their performance status report, everybody gets raises all around, and maybe they go for a nice dinner to celebrate.

Of course, if you look at the big picture, from the asterisk all the way to the exclamation point, nothing has changed. It still takes the same amount of time for the application to be ready from a cold start. All this "performance" improvement did was rob Peter to pay Paul. The time spent doing "Application Startup 1" is now charged against the operating system and not against the application. You shuffled numbers around, but the end user gained nothing.

In fact, the user lost ground. For the above diagrams assume that the user wants to run your application at all! If the user didn't want to run your application but instead just wanted to check their email, they are paying for "Application Startup 1" even though they will reap none of the benefits.

Another example of applications having a selfish view of performance came from a company developing an icon overlay handler. The shell treats overlay computation as a low-priority item, since it is more important to get icons on the screen so the user can start doing whatever it is they wanted to be doing. The decorations can come later. This company wanted to know if there was a way they could improve their performance and get their overlay onto the screen even before the icon shows up, demonstrating a phenomenally selfish interpretation of "performance".

Performance is about getting the user finished with their task sooner. If that task does not involve running your program, then your "performance improvement" is really a performance impediment. I'm sure your program is very nice, but it would also be rather presumptuous to expect that every user who installs your program thinks that it should take priority over everything else they do.

Published Friday, March 11, 2005 1:50 PM by oldnewthing
Filed under:

Comments

# Re:

Friday, March 11, 2005 1:57 PM by Wesha
That's what I call "sweeping the dust underneath the carpet", something the software industry loves to do. Instead of fixing the problem, let's hide the symptoms!

BTW longer startup is not the only impact. It's a waste of [virtual] memory as well -- the app that has been launched during system startup, needs to store its data somewhere, after all.

# re: Performance gains at the cost of other components

Friday, March 11, 2005 2:14 PM by Dan McCarty
I can only read your post with the wryest of smiles, knowing that MS is one of the worst offenders in this area. I hope you wrote it tongue in cheek as well.

Remember how the IE team made their app load faster than Netscape's? I think that a healthy dose of your advice is in order: "assume that the user wants to run your application at all!"

# re: Performance gains at the cost of other components

Friday, March 11, 2005 2:24 PM by Mike Dunn
It bugs me when apps (Office, Real, Quicktime, etc.) do this "trick" just to get the DLLs loaded and into RAM and the HD cache. Never mind that unless I run Office/Real/QT *immediately* after booting, the DLLs will get swapped out over time and will have to reloaded from disk ANYWAY.
It's nice when the "quickstart" app has a tray^H^H^H^Htaskbar notification area icon because then I know to go and rip it out of the startup group.

# re: Performance gains at the cost of other components

Friday, March 11, 2005 2:25 PM by Andreas Magnusson
Ironically I found that the only thing in my Startup folder was Microsoft Office.

# re: Performance gains at the cost of other components

Friday, March 11, 2005 2:45 PM by Johan Ericsson
In being the devil's advocate,

Isn't it possible that the user doesn't care how slow the startup code is? The user may only perform the startup once every few days, whereas they will launch the application much more often.

Doesn't pre-loading an application, in that case, help the user "finish their task sooner"?

# re: Performance gains at the cost of other components

Friday, March 11, 2005 2:50 PM by Neil
Reminds me of handling out-of-memory conditions in kernel mode. You know the system is going down -- but if you can hang in there a little longer then another vendor's driver is at the top of the blue screen. It's about support costs for little companies. If Microsoft gets the call from slow system startup, then we hold onto a little more revenue. Maybe we get a raise or a nice dinner. So true.

# re: Performance gains at the cost of other components

Friday, March 11, 2005 2:50 PM by Simon Cooke [exMSFT]
Dan McCarty wrote:
----------------------------------------------
Remember how the IE team made their app load faster than Netscape's? I think that a healthy dose of your advice is in order: "assume that the user wants to run your application at all!"
----------------------------------------------

What, you mean by rebasing and binding their DLLs? Something that the Mozilla team *have* built into their build process now, making it load as fast as IE (assuming that you turn off "quickstart" and run it with -nosplash as the switch).

Loading things fast isn't magic, you know. It just takes a little bit of knowledge and a little bit of work. Neither of which the Netscape engineers had, even though all of this was documented in books and the MSDN library.

# re: Performance gains at the cost of other components

Friday, March 11, 2005 3:05 PM by SS
I had this experiance when I moved from 2000 to XP. The desktop (start menu) showed up faster than win2k but when I clicked on the shortcut, the application did not start until all the services are started. I had to use msconfig and disable all the unnecessary services and applications.

# re: Performance gains at the cost of other components

Friday, March 11, 2005 3:06 PM by Brian Friesen
I for one don't like it when applications pre-load like this. When I can do so without breaking the application I always remove these entries. AutoRuns by SysInternals is the best utility for this! :)

# re: Performance gains at the cost of other components

Friday, March 11, 2005 3:10 PM by Provoker
Also interesting: Because ms do bundle it's webbrowser with the os, it is installed before mozilla. The transfer rate of an ordinary HD is about 2-3 times faster at the beginning compared to the end of the disk.

# re: Performance gains at the cost of other components

Friday, March 11, 2005 3:15 PM by Robert Kozak
Raymond,

As you demontrated, total startup time has not changed but it is not taking into account the users perception.

Sometimes just adding a splash screen to an application will make it look faster even if it adds more time to the total startup. Because it is more responsive to the user (giving feedback) it is perceived as being faster. So perception is sometimes better than actual performance.

Also by moving initialization startup code of an application into the startup of the OS the user can start and teminiate their application throught the day and get a better accumulated performance benefit. Your diagram only takes into account 1 run of the application. Ideally the OS should only be started once while applications will be started over and over again.

The more stable the OS is and as it increases in total uptime then the inital first load of the OS would soon become a distant memory.

-- Robert


# Cost of startup group is much higher

Friday, March 11, 2005 3:23 PM by Steve loughran
The trouble with startup apps is that you are only moving the startup delay if your app is run *every single boot*.

If you only run the app a fraction of system boots, the effective startup time of an app should be multipled by the fraction of the app. E.g. if you run office 1 in 4 runs, Real 1 in 10, and each startup app takes 10s, the effective cost of office startup is 40s per app run, and 100s for Real.

Startup group apps (and worse, CurrentVersion/Run stuff in the registry) are evil.

# re: Performance gains at the cost of other components

Friday, March 11, 2005 4:17 PM by Robert Kozak
Steve,

My point is that with a stable OS, an application should be run many times per OS boot.

If you are booting a machine every hour this is a major problem but if you boot every week, month or year the cost to put in start up code as part of the OS boot process becomes less and less over time.

-- Robert

# re: Performance gains at the cost of other components

Friday, March 11, 2005 4:51 PM by foxyshadis
One major problem with moving stuff into the startup is that traditionally, windows startup times have been one of the major complaints that people've had about windows - yet new installs are fast, as most also know. The obvious culprit is 'windows cruft' but the real one is the constant onslaught of app developers who assume they know so much better what people want in their startup. It's not the windows team's fault that boorish devs exist, and they made the msconfig tool to help fight it.

Robert, if an app can be split into two to start partly at startup and the rest on load, then it can also be made just as easily to stay resident after the first start. (Photoshop acts this way the last few versions; the first startup is obnoxiously slow, the subsequent ones quite fast.)

It's also true that most people turn their computers off when they're done, for power/noise reasons, because they've been conditioned to, or just because it's the sensible thing to do, like turning a TV off. Only power users and neophytes who think the screen is the computer tend to leave them running all the time.

# re: Performance gains at the cost of other components

Friday, March 11, 2005 5:21 PM by Robert Kozak
Foxy,

Yes your are right in that many people are turning off their computers but most times it goes into a hibernate or suspend mode. The startup doesn't have to happen again.

If we had an OS that never needed a reboot then the startup time is irrelavent. Who cares about a 10 min boot time if you dont have to reboot for 5 years?

In fact the install time for Windows XP can be over 1/2 hour. But its tolerated because it only happends every once in awhile.

I would take a 1 hour boot time in exchange for an OS that only has to be booted 5 years. :-)

-- Robert

# re: Performance gains at the cost of other components

Friday, March 11, 2005 6:13 PM by Tim Smith
I would like to know why these stupid programs think that they are so important that they can waste my memory with their DLLs. If I run different apps, the pages get paged out anyway so why even bother.

Doing this type of junk works great for the primary application for a specific user. The problem is that every twit programmer thinks his application is the most important app you install on your computer.

# re: Performance gains at the cost of other components

Friday, March 11, 2005 7:23 PM by Tom West
Complain as you like, but the vast majority of people do look at the apparent application load time as a significant (often the most significant) measure of speed. Why should an application company choose to harm the perception of its product just to please the few of us whom might be annoyed by the application's presumption? It certainly has contributed greatly to the perception of Office and Explorer as high quality products.

I think it's like security. We gnash our teeth about Microsoft's lack of security, but the truth is most people intensely dislike effective program security because it prevents them from doing what they want. MS has been serving the consumer's actual wants far better than its competitors in that particular fashion. Only recently has the cost become high enough that people are willing to accept the inconvenience that true security causes (and MS has responded with making security more important).

# re: Performance gains at the cost of other components

Friday, March 11, 2005 10:26 PM by Ashod Nakashian
Those who argue that "perception is sometimes better than actual performance." lack the concept of 'shared resources'!

Guess what, your hardware's resources are finite and average joe doesn't have what power users usually have at their diposal. Ironically, some argue that joe six-pack doesn't care much abour performance, rather about the perception of it. How many application can joe affort to have installed on his system before he is back shopping for new hardware?

In the days of Office 6, Fast.exe and iexplorer (Win98) had not only exhausted most of the system's valuable resources (VM, RAM, GDI objects...) at startup, but made other (much more decent) software look sluggish and bulky.

Had every vendor done as MS did, how would our desktop look today? Talk about adware/spyware and softawre hijacking...

-Ash

# re: Performance gains at the cost of other components

Friday, March 11, 2005 11:02 PM by Brian
I wrote an application that ran at start up once. Before it does anything else it sleeps for about a minute. One of the biggest problems I find is that when every program is trying to hit the disk at once, everything goes really slow, but if I wait a minute then I pretty much get the disk all to myself.

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 1:11 AM by J. Edward Sanchez
Take note, all software developers: If you're going to preload your app at startup, make sure to wait exactly one minute before kicking in!

But seriously, there is something to the delayed preload idea. Rather than going on a fixed delay, however, it would probably be better to wait until the user has been idle for a certain amount of time. Thing is, even that could still result in the same problem of all the programs hitting the disk at once.

An even better idea would be for the OS to provide a separate "idle startup list" facility. Apps that wanted to preload themselves could put themselves in that list, and the OS would decide when it was safe (i.e., user idle) to start going through the list and executing the items, waiting for each one to finish before moving on to the next.

This way, a system could be configured so that only the essential stuff would actually run at startup; all the optional preload-type stuff would run later -- or perhaps never at all, if the system never became sufficiently idle.

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 2:38 AM by Simon Cooke [exMSFT]
Ashod:
"In the days of Office 6, Fast.exe and iexplorer (Win98) had not only exhausted most of the system's valuable resources (VM, RAM, GDI objects...) at startup, but made other (much more decent) software look sluggish and bulky"

Fast.edxe might be taking up space, but IE wasn't "exhaust[ing] most of the system's valuable resources".

Boy. You really need to learn how virtual memory and DLLs work. And IE didn't utilize GDI handles when its window wasn't open.

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 2:51 AM by Mat Hall
WRT to preloading stuff, in certain circumstances I'm all in favour of it. After all, I only turn my PC on once a day but I start apps dozens of times, so if there's an additional minute or so cost added to the once off event that shaves 30 seconds off something that I do 10 times a day, I've made a net gain.

Plus, even if there was no ACTUAL gain there's still probably some benefit. I don't know about anyone else, but my morning routine is "turn on PC, wander off to get coffee, have a smoke, chat with a few people, then sit down to actually do something" so it makes no practical difference whether my PC boots in 15 seconds or 15 minutes. (Sure, if you come in to work, sit down at your desk straight away and wait for your PC to fire up before springing in to action then the extra startup time is going to be irritating, but to be honest if that's how you start your day then I find *YOU* irritating and therefore couldn't care less about the issue. :)

Finally, hands up who runs defrag regularly on their machines? Have a guess how often "regular" users run it. I'd say "never" is a fairly good estimate. If they'd get into the habit of occasionally clearing out temporary files, removing no longer useful System Restore entries, compressing old files and then defragging people may find that the interminable wait for an app to start up all of a sudden becomes not so bad. (I may be a bit of an extreme case -- I run defrag after EVERY install/uninstall -- but it's still worth doing at least once a month (depending on how much grief your machine gets).)

[ Apologies for the rambling. ]

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 3:09 AM by Tom West
> Those who argue that "perception is sometimes better than actual performance." lack the concept of 'shared resources'!

Being "good" doesn't help if users delete your application in favor of an application that is "bad", yet seems better in their eyes.

The point is that there are scarce resources on a computer and if your application can seize more of them to produce a better experience for the user (within reason, reformatting the hard drive to place your application in an optimal location is out :-)), then users will likely choose your app over your competitors.

> The transfer rate of an ordinary HD is about 2-3 times faster at the beginning compared to the end of the disk.

Is this really true? If so, I'm certain there's a market for an installer that shifts your application to the best portion of the disk and moves whatever's there elsewhere.

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 4:28 AM by Joker
I love how Raymond managed to use the word "holistic" in a rational, technical discussion =)

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 5:45 AM by Alex Blekhman
Why nobody mentioned delay-load linker feature? It takes the best of two worlds. It doesn’t pollute system’s start up and application starts fast, too.

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 6:11 AM by kalleboo
I like the MacOS X approach, where you can have applications open without any windows.

I keep all the apps I use regularly open all the time, and if I want to play a demanding game or something I can exit apps to free up resources, and then re-open them when I'm done. In fact, right now I have 17 apps open, and I'm only actually using 4 right now.

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 7:10 AM by Martina
Robert,

if the user is loading the app several times during the day, loading parts of it during system startup doesn't matter anymore. This helps only the first time after system startup.

For all further application startups, its files will be in the cache anyway (or not, if the memory has been recycled), with or without the startup trick...

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 8:48 AM by Tim Smith
Ashod> Those who argue that "perception is sometimes better than actual performance." lack the concept of 'shared resources'!

Um, no. In my current application, we have made many perceptual performance improvements without improving the performance of any component in question.

Take for example some form of preview window or status pane whose contents change based on the users currently selection. In a previous version of application, every time the control notified us of a change in the selections, we would update this pane. This made the program seem very sluggish and slow. To remove this problem, we placed the updating of the status on a short timer. This means that operations such as down arrow which quickly change the selection over and over again perform very quickly while the user is still displayed updated information once the selection stops changing for some short delay.

That simple change and others like it has made a huge difference in perception from the users.

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 9:31 AM by Harvey
<blockquote>I like the MacOS X approach, where you can have applications open without any windows.</blockquote>

You mean, minimised?

Anyway I find after loading any program once, it stays in cache unless I purge the cache by loading a game or something that eats all the physical memory. I know that pretty much all the time, Word or Excel or Photoshop will load without having to access the disc, unlesss of course I've just booted the machine.

<blockquote>To remove this problem, we placed the updating of the status on a short timer. This means that operations such as down arrow which quickly change the selection over and over again perform very quickly while the user is still displayed updated information once the selection stops changing for some short delay.</blockquote>

Delaying the updating of a status indicator makes the program seem faster? Erm...

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 9:49 AM by anon
Isn't most of IE a COM widget anyway (or something)? And isn't it used by a lot of applications as well? Thus it makes sense for it to be able to start fast.

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 9:57 AM by Adrian
In many cases, adding application startup code to the system startup actually takes longer. At system startup, there is tremendous competition for resources. Trying to do more things in parallel under those circumstances causes more contention.

On the lighter side, at one company we joked about saving a bitmap image of the main window when the user closes the application. Next time the application is opened, we could blast the image onto the screen, and give the perception that we loaded *very* fast. At least until the user tried to click on something.

Fast startup is a difficult task for any application of moderate complexity and size. A really good architecture can give you a lot of options for improving startup time. Alas, many apps don't have a good architecture. So it doesn't surprise me that lots of large, "mature" apps try to move their startup.

One of the best things you can do is to set appropriate base addresses for all of your DLLs. This is a big win for startup, and, if the system is memory constrained, it helps overall performance, too.

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 11:43 AM by Junfeng Zhang
My little rant about jsched.exe has an insane amount of web view hit, compared to other articles. That says something.

http://blogs.msdn.com/junfeng/archive/2004/02/24/78948.aspx

The biggest offender is (In my opinion) Apple QuickTime 6.x. This guy adds itself to HKLM Run registry everytime you run it!!!

# the impact of preload Hibernate/resume

Saturday, March 12, 2005 1:53 PM by Steve
Another reason against preloading stuff is that they preload stuff into memory, assuming they stay there.

But what happens when the OS hibernates? I think the logic is: anything reloadable (mapped files) gets discarded, being pulled in from the filesys on demand. Anything in swap gets flushed to swap for demand load. Anything not swappable gets saved.

Effectively the time to save/load to disk depends not on the amount of phy mem you have, but the amount of phy mem in active use.

Every quickstart app that consumes physical mem -and they all do, it is their nature- is making the hibernate and resume times of laptops worse. So when people look at a powermac then a windows PC and say "why is windows so bad at suspending", the answer is partially "because of all the quickstart junk"

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 2:37 PM by Mihai
I have read several comments about the improvements you get if you run the application more than once (true).
Also the ones about how important the perception is (I also think it is true).

But here is another point about perception:
- OS start time = MS Windows time
- App start time = Company X time.

If I do the startup trick, then the perception is "MS Windows is soooo slow! But this application is sooo fast and slick! Cool!"

:-)

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 3:26 PM by Rob Meyer
I like J. Edward Sanchez's idea. It really could be extended to be even more general; sort of a "predictive page-in" approach. Keep a list of frequently used pages/disk areas (might take some tricks to stay persistent from boot-to-boot) and during idle time, bring those pages into memory. They'd be read only, so they could be discarded quickly if necessary. That way the system would just tune itself to load the user's most frequently used applications quicker, rather than having to try and have applications fight over who loads first and suck up all the resources in a non-friendly way.

# re: Performance gains at the cost of other components

Saturday, March 12, 2005 9:14 PM by kbiel
I this entry and the resulting comments are funny. It is just further proof that most of us programmers have a big ego and our programs are an extension of that ego. Yes, most of us time we strive to produce something useful, but we also often fall into the trap of adding something or "improving" somthing, just to increase our own prestige.

Thanks Raymond. This entry is more of an exercize in psychology rather than good programming.

# re: Performance gains at the cost of other components

Sunday, March 13, 2005 8:25 AM by Jackson
I agree with Junfeng Zhang. I just HATE QuickTime doing that.

# re: Performance gains at the cost of other components

Sunday, March 13, 2005 10:29 AM by o f f t o p i c
if you hate quicktime look at that:
http://www.codecguide.com/

# re: Performance gains at the cost of other components

Sunday, March 13, 2005 12:04 PM by Simon Cooke [exMSFT]
-------
Rob Meyer:
I like J. Edward Sanchez's idea. It really could be extended to be even more general; sort of a "predictive page-in" approach.
-------

... except that's what XP does already.

-------
foxyshadis wrote:
Robert, if an app can be split into two to start partly at startup and the rest on load, then it can also be made just as easily to stay resident after the first start. (Photoshop acts this way the last few versions; the first startup is obnoxiously slow, the subsequent ones quite fast.)
-------

That's not what Photoshop does. You can see this effect with any app - IIRC, Windows XP and upwards (maybe 2000 as well - I'd have to check) cache DLLs after load, with all of their linking and binding information intact. You only pay the penalty the first time you load an app after booting, at the expense of some disk space. And if you use an app a lot, it'll get cached more extensively for load on startup.

MSDN has more info on this.

-------
Provoker wrote:
Also interesting: Because ms do bundle it's webbrowser with the os, it is installed before mozilla. The transfer rate of an ordinary HD is about 2-3 times faster at the beginning compared to the end of the disk.
-------

You're wrong. If you use Mozilla a lot, next time the disk auto-defrags, it will move the mozilla files to the outside of the disk, along with any other apps that you use a lot, in the order in which it is normally paged into memory.


People - this information is all available online on MSDN and in other sources. Why do so many myths and misconceptions about this exist? Please - go and do some research. It'll make you a better software engineer if you actually UNDERSTAND the tools you're using.

# re: Performance gains at the cost of other components

Sunday, March 13, 2005 1:37 PM by James Summerlin
Simon,

After only reading a few comments by you, I find you already to be super cool.

These misconceptions exist for the following reasons:

1. It's fun to make up stuff about MS. Indeed, people make money off of doing this (think ZDnet).

2. Bad news travels faster than good news.

3. If MS says something bad about linux, even if it's true, then it is FUD. If anyone who uses Linux says anything bad about Microsoft even if it's a lie, it is the GOSPEL TRUTH.

James

# re: Performance gains at the cost of other components

Sunday, March 13, 2005 4:02 PM by Tom West
> this information is all available online on MSDN and in other sources. Why do so many myths and misconceptions about this exist?

There's a lot of knowledge in the Library of Congress too, but people just don't bother to read it all...

Come on, there's way too much documentation (much of it not particularly well structured) for anyone whose job doesn't depend upon it to read. Even when one knows what one wants to find out, MSDN is nearly impenetrable. (Much of which is caused by the fact that it needs to serve a massively diverse bunch of people, making it almost unusable for all of them.) For most of us, the information we're talking about here is merely interesting rather than necessary. We're not going to spend the near full-time effort that it would take to be fully conversant with all the information that Microsoft puts out.

Sites like this one that cater to a much smaller niche of interests than MSDN are a godsend. Most of us are here to learn and disseminate what we believe to be truth. Sometimes we're completely wrong. More often, we *were* right, but now we're wrong. Big suprise. If we were all enlightened, this blog would be a waste of Raymond's time :-).

> this information is all available online on MSDN and in other sources.

As an occasional Windows programmer, I'd love to be enlightened. Let's say I want to learn about fast load times and disabuse myself about these myths. What would I search under? I just searched under "Faster Application Load Times" on MSDN and found nothing of interest. Is it really all that easy to become enlightened? Easy enough that we deserve chastisement for not having already done so?

# re: Performance gains at the cost of other components

Sunday, March 13, 2005 4:24 PM by Andreas Häber
It helps to know the name of the technology: Prefetch. So try this search instead: http://www.google.com/search?q=prefetch+site%3Amsdn.microsoft.com

One of the best is Mark Russinovich and David Solomon's article about Windows XP Kernel improvements: http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/01/12/xpkernel/toc.asp?frame=true

Guess there are two camps about MSDN Library: people who find it disorganized and people who find it easy to use. I'm in the second camp :) I prefer the offline version because of its index.

# re: Performance gains at the cost of other components

Sunday, March 13, 2005 6:41 PM by Tom West
Thanks! And you're absolutely right. The biggest problem is knowing the technology exists at all, and what name it has been given...

# re: Performance gains at the cost of other components

Monday, March 14, 2005 1:00 AM by David Candy
I checked all working sets on my computer. I was pleased to see that almost noone (except office) changed their working sets from the 512K/2M default. Though I'd wager that is only because they haven't thought of it.

# re: Performance gains at the cost of other components

Monday, March 14, 2005 4:34 AM by noob
What's a working set?

# re: Performance gains at the cost of other components

Monday, March 14, 2005 5:22 AM by Rodrigo Strauss
Real Player? :-)

# re: Performance gains at the cost of other components

Monday, March 14, 2005 5:54 AM by Michael Moulton
------------------
Simon Cooke wrote:
You're wrong. If you use Mozilla a lot, next time the disk auto-defrags, it will move the mozilla files to the outside of the disk, along with any other apps that you use a lot, in the order in which it is normally paged into memory.
------------------

Simon,

How does defrag determine what applications we use "a lot"? I hope it doesn't use the same algorithm as Add/Remove Programs, which is nowhere near accurate for me.

# re: Performance gains at the cost of other components

Monday, March 14, 2005 7:15 AM by Jason Spiro
-------
Rob Meyer:
I like J. Edward Sanchez's idea. It really could be extended to be even more general; sort of a "predictive page-in" approach. Keep a list of frequently used pages/disk areas (might take some tricks to stay persistent from boot-to-boot) and during idle time, bring those pages into memory. They'd be read only, so they could be discarded quickly if necessary. That way the system would just tune itself to load the user's most frequently used applications quicker
-------

-------
Simon Cooke:
except that's what XP does already.
-------

Simon, do you mean that XP prefetches all of a user's favorite apps, not just those in the Startup group and the Run registry keys? The msdnmag article referenced above doesn't mention this under 'Prefetch'.

# re: Performance gains at the cost of other components

Monday, March 14, 2005 8:53 AM by Raymond Chen
David Candy: How did working set get mixed in here? At any rate, programs don't "set" their working set; the OS computes their working set based on their memory usage pattern. There is no "default" working set. A small program will have a low working set; a big one will have a large working set.

# re: Performance gains at the cost of other components

Monday, March 14, 2005 10:02 AM by James Curran
>> I hope you wrote it tongue in cheek as well.

Dan,
I don't think it was tongue in cheek as much as Raymond's just being polite. Remember, Raymond works for Microsoft's SYSTEMS division, while the worst offenders are in Microsoft's APPLICATIONS division.

So, in effect, He's saying "Those jerks over in Office are too lazy to speed up their own applications, so they leverage all the work *I* did speeding up initial boot-up. They're making me look bad, to make themselve look good...."

But, as I said, Raymond's too polite to say that....

# re: Performance gains at the cost of other components

Monday, March 14, 2005 10:34 AM by Junfeng Zhang
@Jason Spiro

Yes, check your %windir%/prefetch directory.

# Playing the performance shell game

Monday, March 14, 2005 1:09 PM by Panopticon Central

# re: Performance gains at the cost of other components

Monday, March 14, 2005 2:17 PM by fluffy
I like how OSX handles this - it does all the DLL prebinding stuff when the library is first installed, and saves it into a cache which can just be quickly read into memory on an as-needed basis. Of course that doesn't help with app data which needs loading, but at least there's no need for apps to prefetch DLLs.

# re: Performance gains at the cost of other components

Monday, March 14, 2005 3:50 PM by Jason Spiro
I actually meant to ask:

Simon, do you mean XP preloads my favorite apps' executable code into free RAM when my PC is idle (in cases where those apps aren't running)?

# re: Performance gains at the cost of other components

Tuesday, March 15, 2005 6:09 AM by Antonio Vargas
Fluffy, OSX 10.3 (the currently available one) does two things directly related to disk optimisation:

1. Files smaller than 20Meg are automatically defragged if and when they are used and not already defragged.

2. There is a background filesystem analyzer that reserves the first 5% of the disk for frequently used files, as seen from the kernel. So, if you keep on rebooting a lot, the system will automatically move the booting-neeeded files to the fastest part of the disk, and if you keep your compueter compiling and compiling then it will automatically place all your sources and libs at the start of the disk. "It just works" is true this time ;)

All truth said, I was very surprised upon seeing WinXP booting to a desktop in less than a minute. Very nice job on that :)))

# re: Performance gains at the cost of other components

Tuesday, March 15, 2005 6:10 AM by David Candy
Why mention it. Because it is a way that applications can boost their own performance at the expense of system as a whole.

From PSDK (and there are lots of pages with this warning)

The system sets the default working set sizes. You can also modify the working set sizes using the SetProcessWorkingSetSize function. Setting these values is not a guarantee that the memory will be reserved or resident. Be careful about requesting too large a minimum or maximum working set size, because doing so can degrade system performance.

I presume it was in the PE header. It's the MS compiler that sets 512K/2M standard, maybe it's a C runtime library init. But I read the other week the MS compiler's default is 512/2M (but can't find it). And I have no idea about any non MS program.

# re: Performance gains at the cost of other components

Tuesday, March 15, 2005 7:27 AM by David Candy
I understand that that the vmm steals a page from the process working set regulary to see if it really needed it.

But MS compiled apps will default to 512/2M initial unless changed.

I don't claim any knowledge about machine VMM. After all CSRSS gets preference, foreground apps get preference, minimised apps get un preferenced.

But all this stuff is unimportant. What is important is to live. As you may not know, I failed to save a life two saturdays ago. A lifetime of training and it didn't work.

# re: Performance gains at the cost of other components

Tuesday, March 15, 2005 9:36 AM by Scott Kurtzeborn
If anyone's installed Adobe's Acrobat Reader 7.0 they can see this philosophy in action. I recently installed it and now AcroRd32.exe is a permanent fixture in my task list.

As pointed out in other comments, perhaps this isn't a bad thing *if* you use Acrobat Reader regularly.

# re: Performance gains at the cost of other components

Wednesday, March 16, 2005 1:59 AM by Patrick Schriner
I remove allmost every app from startup.

But wouldn´t it be practical to start runtimes in advance? If you had a dozen programs that need the .NET runtime (or the Java RE), wouldn´t loading the runtime in advance correspond to faster startup for several applications?

# re: Performance gains at the cost of other components

Saturday, March 19, 2005 2:48 AM by A kid
I used Windows XP Professional on 64MB of Memory. I just upgraded my computer from 64MB to 192MB. The performance Tab of Task Manager now shows that there is 100MB free. I don't like any background running programs such as Anti Virus Software. Zonealarm is good enough for mee. I don't even use Themes and in Services 3/4 of the services are switched off.

# re: Performance gains at the cost of other components

Sunday, March 20, 2005 10:35 PM by Aaron Margosis
I needed to install QuickTime on the family computer to support an education app. Rather than install the QT version that came with the app, I downloaded/installed the current version (6.5.2). EVEN WORSE than just adding a regular auto-start entry, they now install a Windows SERVICE that runs as LocalSystem, set to Automatic start! AND EVEN WORSE THAN THAT, it's to support hardware I do not own nor have plans to own - "iPod Service", description: "iPod hardware management services".

# Splitting up the work

Tuesday, June 12, 2007 7:42 AM by Hannes's Mind Maze

I like reading Joel’s blog on software and in his latest post he talks about Apple Safari for Windows

# Stephen&#8217;s Personal Blog &raquo; Blog Archive &raquo; Why is my computer slow?

Tuesday, June 12, 2007 9:25 AM by Stephen’s Personal Blog » Blog Archive » Why is my computer slow?

PingBack from http://stephensite.net/WordPressSS/?p=262

# Faking the performance &laquo; As I Learn

Tuesday, June 12, 2007 9:14 PM by Faking the performance « As I Learn

PingBack from http://countme.wordpress.com/2007/06/13/faking-the-performance/

New Comments to this post are disabled
 
Page view tracker