RE: [SLE] OO: If you can make it, I can break it!
-----Original Message----- From: Hans du Plooy [mailto:hansdp-lists@sagacit.com]
<snip>
I mentioned the other office suites specifically for this reason. Even with the quickstarted (which should give OOo the same advantage), it still takes a good while longer than any other office suite to start. Heck, Word/Excel even starts faster through Crossover Office than OpenOffice does. Which pretty much eliminates the OS aspect of the argument, doesn't it?
2) Windows loads a lot of bloat (even right in the operating system kernel) -- which means a lot of stuff, libraries, etc ... is
I am not sure if crossover office would behave any differently than windows. Maybe a better comparison is how does OOo run on windows (there is a windows version isn't there?)? pre-loaded
and all you are doing is starting a thin interface to it. Doesn't change the fact that OOo starts slow. I really don't care what they do to make it faster.
On my notebook OOo takes 8 seconds to display the spash screen, and another 5 seconds from there to bring up the Writer interface. That is unacceptable. Also doesn't change the fact that, once started, OOo *is* slower than any other office suite to use. When I click on the file menu for the first time, for example, there is a noticeable delay before the menu appears. I just checked, after opening Writer, I click on the "open" button. 4 seconds before the open dialog appears. It feels like working Windows 95 on a 486. Of course, once it is open and running and you've used it a little,
True. The customer experience is the important thing. things
speed up a little. But that's no justification for the really slow start up times.
Hans, I stand corrected -- your numbers seem to indicate true slowness. I haven't been annoyed by the difference myself (except on occasion) and I haven't taken any numbers because of this. Either way, I am still trapped into keeping Windows on one machine because of one specific app anyway (two if I count tax software). You're reference to Windows 95 is interesting -- I've often said that Linux on the desktop is comparable to the 95 experience (although the OS is much better). I think that is an indicator of when we will see parity with the desktop -- as an upper bound: how long was it from launch of 95 to launch of XP (6 years I think). Linux has been in this state for 1.5 to 2 years, leaving 4 years-ish till parity (assuming windows does not make some incredible stride that people will just be unwilling to do without in the meantime -- however MS's new focus on security has them really playing a different game and I don't think they will respond well).
*technologically* superior, per se -- the problem you complain about is about more about customer perception. No it's not. A 12 second difference in starting time is way more than can be blamed on perception.
What I meant by perception here was not really what you perceive, but about the customer experience as different from the actual loading (which I think you addressed above). However, the 12s you mention -- that is not with a *tuned* OOo startup is it? I think the more concerning number is the difference you see in the already loaded app. How does it respond after you have used the tools (which you are comparing) once (on both)?
It's very difficult, for example, to persuade my dad to try out linux on his PC, when I show him all the apps on my computer and they're all much slower than what he's used to, considering he's using a 400mhz celeron with 196mb Ram. There's no way you can explain that kind of difference away.
I think your Dad has to make a decision between his application startup time and your free tech support <grin>.
I don't mean to diss OOo in any way, it is a good product. But it's has a long way to go to catch up with the commercial offerings, and they keep improving to, so it keeps lagging behind. And saying "but Microsoft cheats/does this or that" doesn't do anythign to excuse OOo's shortcomings.
I have to admit, I have neglected in this discussion to draw the point about OOo specifically. <snip> Regards, Patrick
On Wed, 2005-12-28 at 14:46 -0500, Patrick Freeman wrote:
I am not sure if crossover office would behave any differently than windows. Maybe a better comparison is how does OOo run on windows (there is a windows version isn't there?)? The Windows version feels quite a bit faster than the linux version, at least too me. I don't know why that is the case. Maybe the linux port is actually behind the windows one?
I stand corrected -- your numbers seem to indicate true slowness. Bear in mind I'm talking about first time start up after a cold boot. When I open it for a second time it's much faster, but still much slower than I think it should be on this kind of hardware.
You're reference to Windows 95 is interesting -- I've often said that Linux on the desktop is comparable to the 95 experience (although the OS is much better). I think KDE and the way SUSE set things up is way ahead of Windows 95.
I think that is an indicator of when we will see parity with the desktop The problem is that it is a moving target. Having had a chance to look at a pre-release of Windows Vista, there are a few things the KDE devs are going to have to add to please the masses.
(which I think you addressed above). However, the 12s you mention -- that is not with a *tuned* OOo startup is it? No, I'm not awayre of any tricks to tune OOo to start quicker, except for the quicklauncher, which I don't use because I don't want it hogging my memory when I'm not using OOo.
I think your Dad has to make a decision between his application startup time and your free tech support <grin>. Actually my dad has no plans of switching, I just used that as a "what if" example. Anyway, he's got three teenage kids in the house to help him with the computer - seldom calls me for that :-)
Hans
On Thu, 2005-12-29 at 14:08 +0200, Hans du Plooy wrote:
On Wed, 2005-12-28 at 14:46 -0500, Patrick Freeman wrote:
I am not sure if crossover office would behave any differently than windows. Maybe a better comparison is how does OOo run on windows (there is a windows version isn't there?)? The Windows version feels quite a bit faster than the linux version, at least too me. I don't know why that is the case. Maybe the linux port is actually behind the windows one?
I stand corrected -- your numbers seem to indicate true slowness. Bear in mind I'm talking about first time start up after a cold boot. When I open it for a second time it's much faster, but still much slower than I think it should be on this kind of hardware.
You're reference to Windows 95 is interesting -- I've often said that Linux on the desktop is comparable to the 95 experience (although the OS is much better). I think KDE and the way SUSE set things up is way ahead of Windows 95.
I think that is an indicator of when we will see parity with the desktop The problem is that it is a moving target. Having had a chance to look at a pre-release of Windows Vista, there are a few things the KDE devs are going to have to add to please the masses.
(which I think you addressed above). However, the 12s you mention -- that is not with a *tuned* OOo startup is it? No, I'm not aware of any tricks to tune OOo to start quicker, except for the quicklauncher, which I don't use because I don't want it hogging my memory when I'm not using OOo.
Then don't bitch about how s l o w it is to load. That is what the quickstarter is there for. It does the same thing MS does, it pre-loads the libs. Why do you think MS requires a reboot after installing new software, so windows can preload the DLL's and get the app to load faster. Which is why each new version of windows needs newer and faster hardware with more memory to run. Oh, and the quickstarter doesn't use -that- much memory. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
On Thu, 2005-12-29 at 08:09 -0500, Ken Schneider wrote:
On Thu, 2005-12-29 at 14:08 +0200, Hans du Plooy wrote:
(which I think you addressed above). However, the 12s you mention -- that is not with a *tuned* OOo startup is it? No, I'm not aware of any tricks to tune OOo to start quicker, except for the quicklauncher, which I don't use because I don't want it hogging my memory when I'm not using OOo.
Then don't bitch about how s l o w it is to load. That is what the quickstarter is there for. It does the same thing MS does, it pre-loads the libs. Why do you think MS requires a reboot after installing new software, so windows can preload the DLL's and get the app to load faster. Which is why each new version of windows needs newer and faster hardware with more memory to run. Oh, and the quickstarter doesn't use -that- much memory.
from top: 15578 ken 16 0 30728 19m 13m S 0.0 2.5 0:03.02 oooqs looks like it is using all of 19m of memory which will go to cache/buffers anyway if oooqs is not running so if you are concerned about something "hogging" your memory look at what caching/buffering is doing anyway, hogging ALL available memory which makes programs load s l o w e r while trying to get memory for it's process. Perhaps if there was a way to limit the amount of memory used by the cache/buffer system it would help speed up the startup of programs. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2005-12-29 at 08:38 -0500, Ken Schneider wrote:
15578 ken 16 0 30728 19m 13m S 0.0 2.5 0:03.02 oooqs
looks like it is using all of 19m of memory which will go to cache/buffers anyway if oooqs is not running so if you are concerned about something "hogging" your memory look at what caching/buffering is doing anyway, hogging ALL available memory which makes programs load s l o w e r while trying to get memory for it's process. Perhaps if there was a way to limit the amount of memory used by the cache/buffer system it would help speed up the startup of programs.
Actually, the cache/buffer memory makes the system go faster. The more you have there, the faster. That's why the second time you load OOo, without the quickstarter, it loads faster: it doesn't need to read from disk, it is already in memory. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDtEEwtTMYHG2NR9URAgc/AJ9aHfi0p5llJqrcdSPdBpKO5NiaMACcC04V 0c7MTxjNBQAQ3+ROuLwyeq0= =pqPD -----END PGP SIGNATURE-----
On Thu, 2005-12-29 at 21:03 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Thursday 2005-12-29 at 08:38 -0500, Ken Schneider wrote:
15578 ken 16 0 30728 19m 13m S 0.0 2.5 0:03.02 oooqs
looks like it is using all of 19m of memory which will go to cache/buffers anyway if oooqs is not running so if you are concerned about something "hogging" your memory look at what caching/buffering is doing anyway, hogging ALL available memory which makes programs load s l o w e r while trying to get memory for it's process. Perhaps if there was a way to limit the amount of memory used by the cache/buffer system it would help speed up the startup of programs.
Actually, the cache/buffer memory makes the system go faster. The more you have there, the faster.
That's why the second time you load OOo, without the quickstarter, it loads faster: it doesn't need to read from disk, it is already in memory.
But -that- is the whole problem with "perception" with -new- users. They load a program like OO and it takes them forever the first time and they then think that -everything- runs slower. If there was a limit to how much ram was used by cache/buffer, programs would load faster the -first- time because memory would be available the first time it was started. The "perception" that new users need to have is that linux is as fast as MS Windows or better yet faster. The cache/buffer use needs to be a tunable parameter. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2005-12-29 at 18:29 -0500, Ken Schneider wrote:
Actually, the cache/buffer memory makes the system go faster. The more you have there, the faster.
That's why the second time you load OOo, without the quickstarter, it loads faster: it doesn't need to read from disk, it is already in memory.
But -that- is the whole problem with "perception" with -new- users. They load a program like OO and it takes them forever the first time and they then think that -everything- runs slower. If there was a limit to how much ram was used by cache/buffer, programs would load faster the -first- time because memory would be available the first time it was started.
No, you are wrong there; cache memory is freed instantly, the worst problem is disk I/O. OOo is huge, and has to be loaded. You can try very easily: start up your system, get in to X mode with a small memory footprint environment - almost anyone except kde (if you have 1GB, then use kde if you like). Start an xterm with "top" running on it; watch the free free memory display, you should have a lot still, and litle memory dedicated to cache; then start up OOo. You will see little or no diference compared to when the chache is in use, provided there is enough free memory. In fact, it may be slower.
The "perception" that new users need to have is that linux is as fast as MS Windows or better yet faster. The cache/buffer use needs to be a tunable parameter.
No, the kernel knows better than you (we) in this respect. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDtIGTtTMYHG2NR9URAgkmAJ9odoedUesgrzLPjhJnI0/OopHUMQCeIaTP 9yIGQ+15+0usw45BjBiVGpU= =664h -----END PGP SIGNATURE-----
On Thursday, December 29, 2005 @ 3:39 PM, Carlos Robinson wrote:
The Thursday 2005-12-29 at 18:29 -0500, Ken Schneider wrote:
Actually, the cache/buffer memory makes the system go faster. The more you have there, the faster.
That's why the second time you load OOo, without the quickstarter, it loads faster: it doesn't need to read from disk, it is already in memory.
But -that- is the whole problem with "perception" with -new- users. They load a program like OO and it takes them forever the first time and they then think that -everything- runs slower. If there was a limit to how much ram was used by cache/buffer, programs would load faster the -first- time because memory would be available the first time it was started.
No, you are wrong there; cache memory is freed instantly, the worst problem is disk I/O. OOo is huge, and has to be loaded.
You can try very easily: start up your system, get in to X mode with a small memory footprint environment - almost anyone except kde (if you have 1GB, then use kde if you like). Start an xterm with "top" running on it; watch the free free memory display, you should have a lot still, and litle memory dedicated to cache; then start up OOo. You will see little or no diference compared to when the chache is in use, provided there is enough free memory. In fact, it may be slower.
The "perception" that new users need to have is that linux is as fast as MS Windows or better yet faster. The cache/buffer use needs to be a tunable parameter.
No, the kernel knows better than you (we) in this respect.
- -- Cheers, Carlos Robinson
So when are the binaries cached, when you exit the program? I've really never explored this in Linux, but on 'dose, the application binary is cached the first time you open it. That's why if you open something like, say, EXCEL, turn right around and close it, then open it again, it comes up almost instantly the second time. You can also go to task manager and watch the memory hits. If an app is, say, 100K, the first time you open it you take a 200K memory hit. If you close it, memory goes down by 100K (leaving the 100K cached copy). The only time that cached copy would go away is if you needed the memory for some other app. Then it would be aged out. Does Linux work differently? Greg Wallace
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2005-12-29 at 19:07 -0900, Greg Wallace wrote:
So when are the binaries cached, when you exit the program?
No, any file read from disk is cached the first time it is loaded. I don't really know if the method is to cache based on disk sectors doing read-ahead, or if it is file based, or a mixture: I'm not a kernel developer ;-) Once in cache it stays there unless the memory is needed for something else more necessary
I've really never explored this in Linux, but on 'dose, the application binary is cached the first time you open it. That's why if you open something like, say, EXCEL, turn right around and close it, then open it again, it comes up almost instantly the second time. You can also go to task manager and watch the memory hits. If an app is, say, 100K, the first time you open it you take a 200K memory hit. If you close it, memory goes down by 100K (leaving the 100K cached copy). The only time that cached copy would go away is if you needed the memory for some other app. Then it would be aged out. Does Linux work differently?
No, that's the idea. Details might be different, of course. I know that Linux uses all available memory not used for something else as cache. What I remember of windows internals, the memory reserved for cache was fixed: time ago there was a direct map (almost) from disk to cache. I'm not sure nowdays what it does. MsDos had no cache, it was an add on by third parties at first; so they must be using a quite complex method now. You may access the disk directly bypassing the system: what happens to the cache then? Linux is diferent, you access a virtualized filesystem, not the real filesystem below. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDtdMStTMYHG2NR9URAmKAAJsH8aKUdg+ta5RYK7Y4MIhnoXpJDQCfaG1M W2Rn9jPwI40HPCjozr1Lp5g= =Zt3O -----END PGP SIGNATURE-----
On Thursday, December 29, 2005 @ 11:04 AM, Carlos Robinson wrote:
The Thursday 2005-12-29 at 08:38 -0500, Ken Schneider wrote:
15578 ken 16 0 30728 19m 13m S 0.0 2.5 0:03.02 oooqs
looks like it is using all of 19m of memory which will go to cache/buffers anyway if oooqs is not running so if you are concerned about something "hogging" your memory look at what caching/buffering is doing anyway, hogging ALL available memory which makes programs load s l o w e r while trying to get memory for it's process. Perhaps if there was a way to limit the amount of memory used by the cache/buffer system it would help speed up the startup of programs.
Actually, the cache/buffer memory makes the system go faster. The more you have there, the faster.
That's why the second time you load OOo, without the quickstarter, it loads faster: it doesn't need to read from disk, it is already in memory.
Right. Assuming it works like 'doze, the first load causes a memory to memory copy to create a cached version. This should happen very quickly. The majority of the time spent on the initial load is getting the binary(s) off of the disk, which would happen even if there were no caching done. Greg Wallace
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2005-12-29 at 19:30 -0900, Greg Wallace wrote:
Right. Assuming it works like 'doze, the first load causes a memory to memory copy to create a cached version. This should happen very quickly. The majority of the time spent on the initial load is getting the binary(s) off of the disk, which would happen even if there were no caching done.
Correct; but not only binaries, but everything. By the way, I forgot to mention a thing that slows a bit disk access in Linux: the filesystem stores in disk the timestamp when any file is read, ie, a write operation for every an each read. The operation is cached, of course, but it does slow things. You can disable this with the option "noatime" in fstab. I have all my partitions that way for over a year or two and I haven't seen side effects yet. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDtdR4tTMYHG2NR9URApFOAJ9ICp3TzG1FxT1MFo3/HDTbQtivBgCbBaHp F1VIqd03M+0NSAjMZVs1bRA= =X+Ny -----END PGP SIGNATURE-----
On Friday, December 30, 2005 @ 3:45, Carlos Robinson wrote:
The Thursday 2005-12-29 at 19:30 -0900, Greg Wallace wrote:
Right. Assuming it works like 'doze, the first load causes a memory to memory copy to create a cached version. This should happen very quickly. The majority of the time spent on the initial load is getting the binary(s) off of the disk, which would happen even if there were no caching done.
Correct; but not only binaries, but everything.
But just the read only portion is cached, right? The working copy (temporary storage holding values you input but not saved) is modified by what you do while you're modifying a data file but that doesn't change what's cached. The cached copy is just a blank slate, suitable for a pure memory to memory copy if you exit the app and then call it back up. I wouldn't think that any special/seldom used forms would be loaded by default either, but would only be loaded if you actually went to one of those during your edit session. Probably just the initial form that you see when you start the app (and maybe a few commonly used ones) is loaded when you call up the app the first time.
By the way, I forgot to mention a thing that slows a bit disk access in Linux: the filesystem stores in disk the timestamp when any file is read, ie, a write operation for every an each read. The operation is cached, of course, but it does slow things.
You can disable this with the option "noatime" in fstab. I have all my partitions that way for over a year or two and I haven't seen side effects yet.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2005-12-30 at 16:53 -0900, Greg Wallace wrote:
Correct; but not only binaries, but everything.
But just the read only portion is cached, right?
No, also the write operations are cached. I understand that the kernel then sorts the pending write operations to try minimize disk head movements (I saw somewhere keywords to select the sorting algorithm). You can dissable write cache operations with the option "sync" in fstab; for example, if you automount media like floppies or external drives, they are normally mounted sync, so they can be removed fast: but they are slow when writing because the cache is dissabled, mounted sync. The working copy
(temporary storage holding values you input but not saved) is modified by what you do while you're modifying a data file but that doesn't change what's cached. The cached copy is just a blank slate, suitable for a pure memory to memory copy if you exit the app and then call it back up. I wouldn't think that any special/seldom used forms would be loaded by default either, but would only be loaded if you actually went to one of those during your edit session. Probably just the initial form that you see when you start the app (and maybe a few commonly used ones) is loaded when you call up the app the first time.
No, the cache doesn't know about forms or any application internals. It just copies the disk sectors or files into memory and operates there, in memory. If the cache is dirty, modified, then it will be saved to disk promptly, but not inmediately. It is not only binaries, but any file. For the exact details, you would have to ask a kernel developper :-) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDtmWqtTMYHG2NR9URAj7GAJkB4htjNnAKuAW2udQ+gCh2EDlH6wCgi5VM xqWPsIkWzYURPhpCKZb9294= =7oAV -----END PGP SIGNATURE-----
Carlos E. R. wrote:
You can dissable write cache operations with the option "sync" in fstab;
Whether it works is filesystem dependent; according to the mount man-page, 'sync' only works for ext2, ext3 and ufs. /Per Jessen, Zürich -- http://www.spamchek.com/ - managed anti-spam and anti-virus solution. Let us analyse your spam- and virus-threat - up to 2 months for free.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2005-12-31 at 13:13 +0100, Per Jessen wrote:
You can dissable write cache operations with the option "sync" in fstab;
Whether it works is filesystem dependent; according to the mount man-page, 'sync' only works for ext2, ext3 and ufs.
Mmm... I tried time ago with my iomega-zip drive, and formated as fat, it is quite faster mounted "nosync". Or rather, not using "sync". - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDt8CLtTMYHG2NR9URAhMFAJ9Mf0AnzujBgLjHLXzIhRq5xnW/jwCgmMJY 42aaIffPqWoTq7G1EuTwx2s= =xXDP -----END PGP SIGNATURE-----
On Saturday, December 31, 2005 @ 2:04 AM, Carlos Robinson wrote:
The Friday 2005-12-30 at 16:53 -0900, Greg Wallace wrote:
Correct; but not only binaries, but everything.
But just the read only portion is cached, right?
No, also the write operations are cached. I understand that the kernel then sorts the pending write operations to try minimize disk head movements (I saw somewhere keywords to select the sorting algorithm). You can dissable write cache operations with the option "sync" in fstab; for example, if you automount media like floppies or external drives, they are normally mounted sync, so they can be removed fast: but they are slow when writing because the cache is dissabled, mounted sync.
(temporary storage holding values you input but not saved) is modified by what you do while you're modifying a data file but that doesn't change what's cached. The cached copy is just a blank slate, suitable for a pure memory to memory copy if you exit the app and then call it back up. I wouldn't think that any special/seldom used forms would be loaded by default either, but would only be loaded if you actually went to one of those during your edit session. Probably just the initial form that you see when you start the app (and maybe a few commonly used ones) is loaded when you call up the app the first time.
No, the cache doesn't know about forms or any application internals. It just copies the disk sectors or files into memory and operates there, in memory. If the cache is dirty, modified, then it will be saved to disk promptly, but not inmediately. It is not only binaries, but any file.
For the exact details, you would have to ask a kernel developper :-)
- -- Cheers, Carlos Robinson
But if I exit an app and then call it back up, I don't want to have any "data" from the previous execution. In order to get that so called clean slate, the app has to either get the clean slate (so to speak) from disk or from cache. So, a clean copy should be in the cache ready to serve up if I try to call the app up again later in my session. At least that's the way I understand it to work in the 'doze world. Greg Wallace
Greg, On Saturday 31 December 2005 21:51, Greg Wallace wrote:
...
But if I exit an app and then call it back up, I don't want to have any "data" from the previous execution. In order to get that so called clean slate, the app has to either get the clean slate (so to speak) from disk or from cache. So, a clean copy should be in the cache ready to serve up if I try to call the app up again later in my session. At least that's the way I understand it to work in the 'doze world.
My god, what is your obsession with this?! Does the application malfunction? Have you ever seen stale data from a previous run when you re-launch? Of course not. Do you think anything that's exchanged here is going to change how long it takes OpenOffice.org (or any other program) to start up on any given invocation? I hope you don't. If you cannot accept that these most fundamental aspects of the pertinent application and system software are correctly programmed and simply adopt the user perspective, then go out and buy some books on the principals of operating systems in general and of the Linux OS in particular and educate yourself. But all this stupid guessword and uninformed speculation is maddening (and it's made all the worse by the repeated and inane use of the inane term "'doze"). Otherwise, just as you accept that pilots and flight crews and maintenance crews know what they're doing with the airplanes you fly, I suggest you use software as if it's working until it gives you evidence that it is not. Sheesh.
Greg Wallace
Randall Schulz
On Saturday, December 31, 2005 @ 9:08 PM, Randall Schulz wrote:
Greg,
On Saturday 31 December 2005 21:51, Greg Wallace wrote:
...
But if I exit an app and then call it back up, I don't want to have any "data" from the previous execution. In order to get that so called clean slate, the app has to either get the clean slate (so to speak) from disk or from cache. So, a clean copy should be in the cache ready to serve up if I try to call the app up again later in my session. At least that's the way I understand it to work in the 'doze world.
My god, what is your obsession with this?! Does the application malfunction? Have you ever seen stale data from a previous run when you re-launch? Of course not. Do you think anything that's exchanged here is going to change how long it takes OpenOffice.org (or any other program) to start up on any given invocation? I hope you don't.
If you cannot accept that these most fundamental aspects of the pertinent application and system software are correctly programmed and simply adopt the user perspective, then go out and buy some books on the principals of operating systems in general and of the Linux OS in particular and educate yourself. But all this stupid guessword and uninformed speculation is maddening (and it's made all the worse by the repeated and inane use of the inane term "'doze").
Otherwise, just as you accept that pilots and flight crews and maintenance crews know what they're doing with the airplanes you fly, I suggest you use software as if it's working until it gives you evidence that it is not.
Sheesh.
Greg Wallace
Randall Schulz
Randall: If it sounded like I was ranting I certainly didn't intend that. I think OO works fine, at least on my machine. When I entered this thread, there seemed to be a question of whether the caching done by OO was a drag on the system and there was talk of it needing to be turned off, as if it was a bad option to have in the first place (at least that's the way I read those earlier posts). I didn't think it was a bad option and didn't think it would be the cause of poor performance, unless the machine's memory was just overtaxed in general. I was simply trying to comment on that. Then, admittedly, those last few posts went off on a bit of a tangent, and I do apologize for that. I indeed feel that "these most fundamental aspects of the pertinent application and system software are correctly programmed", just as you say. Greg W
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2005-12-31 at 22:49 -0900, Greg Wallace wrote:
If it sounded like I was ranting I certainly didn't intend that. I think OO works fine, at least on my machine. When I entered this thread, there seemed to be a question of whether the caching done by OO was a drag on the system and there was talk of it needing to be turned off,
I think your confusion is that you think this cacheing is done by OOo. It is not, it is done by the kernel, the same as it is done for every single application and file read or written in the system. OOo knows nothing about it, it is transparent. The only thing that OOo can do, with the quickstarter, is to run another app whose task is simply to say to the system: "I want to use such and such libraries, so please activate, load, run them or whatever you have to do so I can use them" - except that it really doesn't use them, but the result is that they are loaded ready for when the user really decides to run OOo. It is just a trick. This doesn't have anything to do with cache, it occupies memory with binaries, leaving less memory for other uses - like cache, for instance: it will in fact slow down other system uses. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDt8gntTMYHG2NR9URAm7EAJ91zyM+Xpmbr0lQQnE+9rEe0Y2wAACgmVuU a9Vv6/gnT+42KuI3Lls8Bns= =qQZo -----END PGP SIGNATURE-----
On Sunday, January 01, 2006 @ 3:17 AM, Carlos Robinson wrote:
The Saturday 2005-12-31 at 22:49 -0900, Greg Wallace wrote:
If it sounded like I was ranting I certainly didn't intend that. I think OO works fine, at least on my machine. When I entered this thread, there seemed to be a question of whether the caching done by OO was a drag on the system and there was talk of it needing to be turned off,
I think your confusion is that you think this cacheing is done by OOo. It is not, it is done by the kernel, the same as it is done for every single application and file read or written in the system. OOo knows nothing about it, it is transparent.
The only thing that OOo can do, with the quickstarter, is to run another app whose task is simply to say to the system: "I want to use such and such libraries, so please activate, load, run them or whatever you have to do so I can use them" - except that it really doesn't use them, but the result is that they are loaded ready for when the user really decides to run OOo.
It is just a trick.
This doesn't have anything to do with cache, it occupies memory with binaries, leaving less memory for other uses - like cache, for instance: it will in fact slow down other system uses.
- -- Cheers, Carlos Robinson
I see. Yes, I was confused about it. Now I see what you're saying. Based on what you are saying, it would seem that the amount of spare memory you had on your machine would be the determining factor, right? I you had lots of spare memory, then it would seem that using the quickstarter wouldn't impact your other activities; whereas, if you were constantly pushing the limits on your memory, it would slow down your other apps. Would that be right? Thanks, Greg Wallace
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-01-01 at 13:47 -0900, Greg Wallace wrote:
I see. Yes, I was confused about it. Now I see what you're saying. Based on what you are saying, it would seem that the amount of spare memory you had on your machine would be the determining factor, right? I you had lots of spare memory, then it would seem that using the quickstarter wouldn't impact your other activities; whereas, if you were constantly pushing the limits on your memory, it would slow down your other apps. Would that be right?
Exactly. The more memory you have available, the larger cache you get, and the less physical usage of disk i/o. Linux benefits a lot from having lots of memory. Thus, if you have a file server (an ftp server, for instance), and have enough memory, your users will not have to wait till the disk can attend their request. A real sample of that was commented not long ago here. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDuHVltTMYHG2NR9URAiVAAJ4lMCIfFzllWxD4B28IhC29APLBZwCfQOyX 8eTwqF6pNFis8xmaLqttlmU= =0FSp -----END PGP SIGNATURE-----
On Sunday, January 01, 2006 @ 3:36 PM, Carlos Robinson wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Sunday 2006-01-01 at 13:47 -0900, Greg Wallace wrote:
I see. Yes, I was confused about it. Now I see what you're saying. Based on what you are saying, it would seem that the amount of spare memory you had on your machine would be the determining factor, right? I you had lots of spare memory, then it would seem that using the quickstarter wouldn't impact your other activities; whereas, if you were constantly pushing the limits on your memory, it would slow down your other apps. Would that be right?
Exactly.
The more memory you have available, the larger cache you get, and the less physical usage of disk i/o. Linux benefits a lot from having lots of memory. Thus, if you have a file server (an ftp server, for instance), and have enough memory, your users will not have to wait till the disk can attend their request. A real sample of that was commented not long ago here.
- -- Cheers, Carlos Robinson
Got it! Thanks for the info. Greg W
On Thu, 2005-12-29 at 08:09 -0500, Ken Schneider wrote:
Then don't bitch about how s l o w it is to load. That is what the quickstarter is there for. It does the same thing MS does, it pre-loads the libs. Why do you think MS requires a reboot after installing new software, so windows can preload the DLL's and get the app to load faster. Which is why each new version of windows needs newer and faster hardware with more memory to run. Oh, and the quickstarter doesn't use -that- much memory.
Maybe my understanding of this is wrong, but I thought the quickstarted is there to do what windows do with MS Office's dlls. Oh, and by the way, Windows doesn't just load half of office all by itself. There's an app, similar to the oooqs that does that. It used to be called osa.exe, I think recent versions call it something else. I'm not going to argue about this any more - it's pointless. Hans
participants (7)
-
Carlos E. R. -
Greg Wallace -
Hans du Plooy -
Ken Schneider -
Patrick Freeman -
Per Jessen -
Randall R Schulz