Firefox high mem

[mauro]

Hi, have Firefox 45-9-0 on OS2 W 4.52 guest machine in Virtualbox, 1024 Mb ramsize.  It runs good, just have to say that it takes almost 30 secs to appear after the first start in the session but after that is ok, then it takes much less when recalled again.
I've seen an item called Firefox highmem in the ANPM repositories, do you know if once installed it could take improvements to Firefox?
Thank you

[Dave Yeo]

It really depends on your usage patterns including what else you run. It'll give you more lower memory for running other stuff but if you only occasionally use Firefox and not much else in OS/2 it might not make much difference.
If you do try it you also should use mozturbo https://bitbucket.org/dryeo/mozturbo/downloads/ to keep the DLLs loaded as your kernel doesn't have some of the fixes for unloading the DLLs when loaded high. Mozturbo should speed up loading too.
It might help more to give your virtual machine another 1/2 a GB of memory

[mauro]

Hi, have Firefox 45-9-0 on OS2 W 4.52 guest machine in Virtualbox, 1024 Mb ramsize.  It runs good, just have to say that it takes almost 30 secs to appear after the first start in the session but after that is ok, then it takes much less when recalled again.
I've seen an item called Firefox highmem in the ANPM repositories, do you know if once installed it could take improvements to Firefox?
Thank you

ok, that is good to know, I'll apply the suggestions for Firefox himem and Moztubo. Repeat it is actually taking a little bit more to run at the first time start, nothing else.  Talking about ram size, I read somewhere that OS2 can work only up to 512 Mb, so more than that is useless.
Thank you

[Dave Yeo]

[Talking about ram size, I read somewhere that OS2 can work only up to 512 Mb, so more than that is useless.
Thank you

That's not really correct. Traditional OS/2 can only use up to 512 MBs (minus system needs) of address space. it's a multi-tasking system so multiple processes can each use up to 512 MBs of private address space and can share (DLLs and such) 512 MBs (actually more like 300 MBs after loading the system) of shared address space. so even then more real memory is better.
OS/2 Warp server along with the desktop after Warp v4+fp13, which unified the kernel etc with Warp Server, can also use high memory above 1GB. Firefox will allocate memory in the high arena if possible and the highmem package marks the DLLs in such a way that the system will  load the DLLs high.
Firefox itself can easily use over 512 MBs of memory if you open lots of tabs and likely won't even be worth trying to run on older versions of OS/2

[xynixme]

I assume ABOVE512.EXE can be used too, to mark that single and unused FF/SM dictionary DLL (code & data) as high?

[Dave Yeo]

I assume ABOVE512.EXE can be used too, to mark that single and unused FF/SM dictionary DLL (code & data) as high?

Sure, it basically does the same thing. marking data as high is usually discouraged as it can cause problems, your mileage may vary.
Which dictionary DLL?

[xynixme]

marking data as high is usually discouraged as it can cause problems, your mileage may vary.
Which dictionary DLL?

Thanks, I'll restrict it to code and - so far - to this single DLL only. AFAIK I have no need to start experimenting with varying mileages.

The manually installed HUNSPEL0.DLL, which AFAICT just has to be loadable and isn't used by any other app. And if another app is using it, then such an app never complained about missing "spell checker's data files".

[Dave Yeo]

The manually installed HUNSPEL0.DLL, which AFAICT just has to be loadable and isn't used by any other app. And if another app is using it, then such an app never complained about missing "spell checker's data files".

SeaMonkey actually doesn't use hunspell as I seem to have neglected to add the line,

Code: [Select]

ac_add_options --enable-system-hunspell
to my .mozconfig.sm file.
Thunderbird and Firefox do use it. Currently I'm not aware of anything else using hunspell.

Edit, Sm actually uses the intree version of hunspell so it is in xul.dll.

[xynixme]

Thunderbird and Firefox do use it. Currently I'm not aware of anything else using hunspell.

Edit, Sm actually uses the intree version of hunspell so it is in xul.dll.

It was a technical requirement of FF and/or SM indeed, but without "dictionary files" I doubt it does anything that's meaningful. So AFAICT it just has to be loadable. Well, and maybe return "NO" when SM queries if Russian is an installed "dictionary".

IOW: I've got the DLL, but no files like hunspell-ru-0_99g5-1_oc00.zip.

Later I may try to mark the other mentioned DLLs of your high loadable DLL list as high, like the larger ICUDT.DLL.

BTW, so far no more rather rare SYS2070s with e.g. SMTURBO.EXEs if that's the only xxxTURBO.EXE in use. Often the other one in use was MOZTURO.EXE. I'll reduce the number of xxTURBO.EXEs in use per system to 1, the best match for that system.

[Dave Yeo]

Well, with SM, it'll use the profile installed dictionary just like previous versions. You're probably right with FF and TB.
I added LIBPATHSTRICT to my xxturbo's and they can co-exist. The original mozturbo doesn't have this and would need wrapping in a script to set LIBPATHSTRICT and BEGINLIBPATH if you want it to coexist with my builds.

[xynixme]

IIRC I always had Mozilla dictionary add-ons/plug-ins for FF/SM, and I'm not sure if I want to know where Hunspell data files have to be saved. Typing, FF and a 1 GHz Pentrium III CPU may be a fatal combination, but I tend to use and prefer SM anyway.

Hunspell may be faster than Mozilla's solutions, but it works with nothing but the DLL installed. It wasn't an intentional and tested choice (speeds, memory usage, ...). It was a matter of installing nothing but Yet Another Required And Unimported DLL, which worked.

I added LIBPATHSTRICT to my xxturbo's and they can co-exist. The original mozturbo doesn't have this and would need wrapping in a script to set LIBPATHSTRICT and BEGINLIBPATH if you want it to coexist with my builds.

Recently I was testing FFTURBO.EXE XOR SMTURBO.EXE, and MOZTURBO.EXE. I'll try to assign LIBPATHSTRICT=T and BEGINLBPATH=xxx to the MOZTURBO.EXE object in the <WP_START> folder first, with the same xxx an own install script assigns to Mozilla object(s) installed by eCS.

If that doesn't work, then I'll write a script. Perhaps even a delay (command "SLEEP.EXE 1 & SMTURBO.EXE") could work, to avoid some race condition or whatever.

FWIW: SYS2070s always happened with SMTURBO.EXE (not used with FFTURBO.EXE), after probably less than 5% of boots, it seems like SMTURBO.EXE was no longer in the tasklist when the SYS2070 popped up, and a reboot was required to browse.

[Dave Yeo]

Hunspell is included with the Mozilla source and is compiled into SeaMonkey's xul.dll. The default en-US dictionary is in your SeaMonkey program directory under dictionaries. What you added were more dictionaries.
As for what else uses hunspell, see

Code: [Select]

https://hunspell.github.io/, a surprising number of programs and even operating systems, including our port of OpenOffice I assume.
The data files for our hunspell port go into @UNIXROOT/usr/share/myspell. Myspell dictionaries are compatible.

What was the sys2070? So far I've only seen it with this build I'm using (unreleased) which is linked against the newest libcx when testing on a new install with an older libcx.
All the latest builds of FF, Sm, and TB set LIBPATHSTRICT in their own so scripts should be unneeded.

[xynixme]

What was the sys2070?

FTR: solved. No more SYS2070s since using your MOZTURBO.EXE, replacing IBM's legacy MOZTURBO.EXE installed by eCS 1.x.