OS/2, eCS & ArcaOS - Technical > Storage

JFS cache sizing, and system "speed-up"

<< < (8/8)

Doug Bissett:

--- Quote --- "browser.cache.disk.parent_directory;H:\mozilla\firefox"
--- End quote ---

I tried that, with the appropriate changes. I really don't notice any difference, but I do have Firefox set to clear everything at shut down anyway. My RAMDISK doesn't retain information over a reboot (my choice, and I never tried it), but that shouldn't change anything. I didn't spend much time with it, but now, how do I remove that entry properly?

I did up my cache to 256000, on my main machine. It created the cache, but then Firefox won't start, complaining that XUL is defective. I put it back to 132000 and it is working.

Then, I have been playing with LW, MIN and MAX buffers. That is possibly making some difference. I will know more on Monday morning, when I do my backups. There is an indication that the single processor machine doesn't like it much, so that will go back to what it was (the LW part anyway).

Dariusz Piatkowski:

--- Quote from: Dave Yeo on November 26, 2021, 04:54:18 pm ---My ramdisk does persist over warm reboots (last computer, it even persisted over a couple of seconds of no power) and every time the browser crashes, which is too often lately, the whole cache gets invalidated.

--- End quote ---

Ahh...got ya! My machine does not retain the ramdisk contents, I had originally tried to do what you are talking about becuase I rarely actually physically shut OFF the machine. Instead it's almost always a re-boot.


--- Quote from: Dave Yeo on November 26, 2021, 04:54:18 pm ---...As for Thunderbird, I'd think the cache is mostly used when displaying web pages, which it is quite capable of doing. I even have an add-on, thunderbrowse, which exposes displaying web pages.
For SM, you can point the cache in the Preferences under Advanced-->Cache. I assume that for TB, you have to open the Options-->Advanced-->Config Editor and create the same preference as for Firefox.

--- End quote ---

Well, it didn't take long for me to read up on the TB specifics. The FF parameter setting is exactly what TB works with. I initially shifted my TB cache to the ramdisk, but then noticed something, see further details below...

Now there is something that seems different, although maybe that's just because I previously did NOT pay attention to it: in TB each time I click on a different folder I now have the clock icon pop up for just a couple of seconds. I honestly do NOT remember seeing this before, and of course I have no idea if this is a result of moving the cache to the ramdisk.

So to test this out, I've actually gone back to a DISK based cache, will give it a few days worth of use and see if that's what causing it.

EDIT
====
Each time the clock icon pops up I do see TCPIP traffic...so TB is certainly fetching something. Haven't captured that and pumped it through Wireshark yet to see what it's actually doing, but I suspect it's going to the server to read something.

Dariusz Piatkowski:
Hi Doug,


--- Quote from: Doug Bissett on November 26, 2021, 05:58:22 pm ---...I did up my cache to 256000, on my main machine. It created the cache, but then Firefox won't start, complaining that XUL is defective. I put it back to 132000 and it is working.

Then, I have been playing with LW, MIN and MAX buffers. That is possibly making some difference. I will know more on Monday morning, when I do my backups. There is an indication that the single processor machine doesn't like it much, so that will go back to what it was (the LW part anyway).

--- End quote ---

Is XUL marked to load high? Otherwise the only follow-up is to see if it's been LXLITE compressed? (not sure if DLLs get processed by LXLITE, I think they do...?)

Re: LW, MIN and MAX, same here. As I change these I continue to log to see they impact these are having.

Dave Yeo:

--- Quote from: Dariusz Piatkowski on November 26, 2021, 07:11:36 pm ---Is XUL marked to load high? Otherwise the only follow-up is to see if it's been LXLITE compressed? (not sure if DLLs get processed by LXLITE, I think they do...?)

--- End quote ---

During make package, all the DLL's and the exe get lxlited. Raw xul.dll, 71,299,848 bytes.

@Doug,
Right click on the preference and choose reset would probably work. Otherwise with the browser closed, edit prefs.js and delete the line, after backing up prefs.js.

Doug Bissett:

--- Quote ---Is XUL marked to load high? Otherwise the only follow-up is to see if it's been LXLITE compressed? (not sure if DLLs get processed by LXLITE, I think they do...?)
--- End quote ---

They are all marked for high code. LXLITE is whatever they were shipped as. I am going to stay with /cache:132000 on my main machine. That seems to work as well as anything else. Changing Lazy write to /LW:16,60,12 doesn't seem to increase performance much. but it does seem to smooth out some of the peaks and valleys. I think I will put that back to /LW:8,30,6 and see what happens. /MINBUFFER:4500 /MAXBUFFER:15000 seem to be good numbers, for me.


--- Quote ---@Doug,
Right click on the preference and choose reset would probably work. Otherwise with the browser closed, edit prefs.js and delete the line, after backing up prefs.js.
--- End quote ---

Okay, that works. It is not exactly obvious what Reset is going to do.

Navigation

[0] Message Index

[*] Previous page

Go to full version