| |||||||||||||
Real-life optimization workReal-life optimization workPosted Nov 2, 2005 22:41 UTC (Wed) by azhrei_fje (guest, #26148)In reply to: Real-life optimization work by cdmiller Parent article: All hail the speed demons (O'Reillynet)
Perhaps. But you're comparing software that didn't/couldn't do what we wanted it to, with software that has more features than mere mortals are likely to ever use. Given that, I will say that I think startup times are pretty bad. But I don't think it's bloat. I think that startup times are linked to building the GUI interface, and I think much of that interface is built without any parallelism. Just in playing around with a Java program of mine, I found that a lot can be built either in a separate thread or when the program goes idle waiting for user input. In both cases, the *apparent* response time was very much improved.
(Log in to post comments)
Real-life optimization work Posted Nov 4, 2005 7:25 UTC (Fri) by drag (subscriber, #31333) [Link] In gnome much of the start up time in programs doesn't have anything to do witth the binary sizes, or how it's programmed, or libraries it's linked to or anything like that.
What it is is that it's looking around on your harddrive for various configuration files and whatnot. Polling files here and there. So a large part of the start up time is when the program is fine and ready to run pretty much, but it is waiting on disk I/O.
With windows you have the registry were all this stuff is stored, which I suppose is mostly in memory most of the time anyways. It's much quicker interface then the Linux-style configuration files and directories stored in various places on your directory system.
That's the trouble with optimizing code. You could spend all day twiddling bits and re-aranging this or that and save maybe a half a second off a 7 second load time, were as you could spend time re-thinking out how the configuration files work and save 5 seconds off of the load time.
Linux itself also has numerious small things that have been developed and added to the kernel to greatly improve memory performance and whatnot, but nobody uses them because they are unaware of them, and when they are they often don't want to bother because it's a hassle to make Linux-specific code when other systems like the BSDs aren't nearly as sophisticated desktop-wise.
Or something like that. I am not a programmer though. But I found this interesting:
Real-life optimization work Posted Nov 6, 2005 8:08 UTC (Sun) by zblaxell (subscriber, #26385) [Link] The Windows registry is organized into a vaguely tree-like recursive structure, demand-paged and cached in RAM.
The Linux filesystem is organized into a vaguely tree-like recursive structure, demand-paged and cached in RAM.
Performance-wise there isn't much difference unless you're using a braindead filesystem. The frequently accessed and recently modified stuff will be in RAM, and everything else won't.
It would be better to tweak the demand-paging of the executables. Reading 4K at a time according to quasi-random execution paths is stupid when it's faster to read 500K of data from disk than it is to read 4K, seek 492K ahead, and read 4K.
Real-life optimization work Posted Nov 9, 2005 10:16 UTC (Wed) by njhurst (guest, #6022) [Link] I think that the problem is each application looks in 10 different places for 10 different files.
Real-life optimization work Posted Nov 8, 2005 8:17 UTC (Tue) by piman (subscriber, #8957) [Link] > You could spend all day twiddling bits and re-aranging this or that and save maybe a half a second off a 7 second load time, were as you could spend time re-thinking out how the configuration files work and save 5 seconds off of the load time.
I'll believe that when I see a profile.
(Which, in my opinion, was rather the point of this article. Stop complaining and start profiling. That's how we'll get rid of "bloat".)
|
|||||||||||||