time frame for a better x64 browser?

Users and developers helping users with technical Pale Moon issues (Windows and other non-Linux O.S.). Please direct questions about the Linux version to the appropriate Linux board.

Moderators: trava90, satrow

Forum rules
This board is for technical/usage questions and troubleshooting for the Pale Moon browser only. The main focus here is on Pale Moon on Windows. Please direct your questions for Linux, Android and Mac to the dedicated boards.
Technical issues and questions not related to the Pale Moon browser should be posted in "technical chat"
Please keep off-topic and general discussion out of this board, thank you!
dabruro

Re: time frame for a better x64 browser?

Unread postby dabruro » Wed, 13 Jun 2012, 18:55

satrow wrote:The tests I've run indicate that x64 Mozilla versions use around 20-30% more memory than their x86 counterparts - ....


That's what I suspected. It makes it really questionable whether the performance gains from using x64 version outweigh the extra memory usage, unless you have truly huge amounts of RAM.

(I have 8GB but I still fill that up sometimes, so I like to conserve memory. When I had 3GB (32bit XP) I thought 8GB would be more than enough, but somehow my usage has gone way up with Win7 x64, perhaps because of the footprint of Win7 and also 64-bit software in general.)

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 22409
Joined: Sun, 28 Aug 2011, 17:27
Location: 58.5°N 15.5°E
Contact:

Re: time frame for a better x64 browser?

Unread postby Moonchild » Wed, 13 Jun 2012, 20:25

As an aside, 32-bit OSes will not be able to address more than 4GB minus reserved top memory. In most cases 3.25 or 3.5GB addressable space at most.
I sincerely doubt you will be actively using all the memory Win7 x64 allocates since a large portion is used as "stand-by" memory that is allocated and used for e.g. caching. Application memory use will always be able to use the "stand-by" memory at a moment's notice.

Considering the memory footprint overall of Pale Moon x64, 20-30% more will not be a great issue on a system running a 64-bit O.S. (that should, like in your case, have memory to spare and a larger pool to begin with)

Pale Moon x64 shows better overall efficiency than the 32-bit version on 64-bit OSes, but of course it's a trade-off. Mostly though, it's the compatibility trade-off (with plugins and other binaries) that is significant, and not the memory footprint. If you have the ram, why not use it?
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

dabruro

Re: time frame for a better x64 browser?

Unread postby dabruro » Wed, 13 Jun 2012, 23:24

Moonchild wrote:...
I sincerely doubt you will be actively using all the memory Win7 x64 allocates since a large portion is used as "stand-by" memory that is allocated and used for e.g. caching. Application memory use will always be able to use the "stand-by" memory at a moment's notice.
...

I'm going by the Commit count, which starts out at about 2.5GB before I even open an application, and then can go up by 1 or 2 GB (representing unshared Working Set) for each instance of some interactive data analysis software that I use for my job. No doubt some of this could be paged out if necessary, but I find performance to be unpredictable once that starts happening much, so I try to avoid it.

dabruro

Re: time frame for a better x64 browser?

Unread postby dabruro » Wed, 13 Jun 2012, 23:29

Hmmm, is it possible to install both the 32bit and 64bit versions of PM and sometimes run one and sometimes the other (using the same Profile)? If nothing else it might re-check your add-on compatibility each time you switch (I've seen that switching between FF and WaterFox), but that's only a minor annoyance.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 22409
Joined: Sun, 28 Aug 2011, 17:27
Location: 58.5°N 15.5°E
Contact:

Re: time frame for a better x64 browser?

Unread postby Moonchild » Thu, 14 Jun 2012, 00:13

Looking at commit charge isn't very useful when you want to know the actual memory use of a process - it merely states the maximum amount of memory (i.e. a limit) of the process' memory that may be committed to swap if needed. It doesn't say anything about your actual memory use.

As for using 32-bit/64-bit alternatively: shouldn't be a problem at all. You'll probably get the compatibility check window indeed when you do that as the version identifier is different.
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

stravinsky

Re: time frame for a better x64 browser?

Unread postby stravinsky » Thu, 14 Jun 2012, 04:17

I sincerely doubt you will be actively using all the memory Win7 x64 allocates since a large portion is used as "stand-by" memory that is allocated and used for e.g. caching. Application memory use will always be able to use the "stand-by" memory at a moment's notice.


+1

which basically means that with win7 , the more memory you have, the more win7 will use for caching. these steps are done to reduce the mechanical disk usage. I'd rather have high RAM usage than high HDD usage. HDD are painfully slow.
with modern SSD's, this is usually not needed. they already are fast enough.
and if you have RAM, why not use it? thats what its for.

dabruro

Re: time frame for a better x64 browser?

Unread postby dabruro » Thu, 14 Jun 2012, 15:45

Moonchild wrote:As for using 32-bit/64-bit alternatively: shouldn't be a problem at all. You'll probably get the compatibility check window indeed when you do that as the version identifier is different.


Okay, so maybe the question of which to use has an easy answer: install both, use the x64 one, and if you run into a compatibility issue or you run low on memory, just exit, run the 32-bit version, and History --> Restore Previous Session! [edit clarified "restore session"]

Moonchild wrote:Looking at commit charge isn't very useful when you want to know the actual memory use of a process - it merely states the maximum amount of memory (i.e. a limit) of the process' memory that may be committed to swap if needed. It doesn't say anything about your actual memory use.


Doesn't paging begin more or less when commit count exceeds physical memory? In any case, actual I/O to my pagefile on disk is what I'm trying to avoid. In theory paging out some not-actively-used memory is okay, but in practice I find it's hard to predict when you'll get to the point where you do see annoying responsiveness slowdowns.

If x64 PM uses 20-30% more memory than 32bit, is there any reason to doubt that at least some of that extra will be "actively" used?

BTW, I saw an interesting bit about memory usage of browsers; the Chrome developers say the "correct" measure is PrivateWS+(ShareableWS-SharedWS). Which equals totalWS-SharedWS. In other words, WorkingSet that *can* be shared with someone else (i.e. it's "shareable" rather than private) still counts unless it *is* in fact Shared with someone else! Unless of course that someone else is only another process of the same browser.

Chrome's about:memory shows the memory usage of any running browsers it recognizes (such as FF) -- too bad it doesn't recognize PM.

Apologies if I've strayed off-topic...

User avatar
satrow
Forum staff
Forum staff
Posts: 1703
Joined: Thu, 08 Sep 2011, 11:27

Re: time frame for a better x64 browser?

Unread postby satrow » Thu, 14 Jun 2012, 16:19

Controlling I/O to the pagefile is pretty difficult - even if you disable the page file, Windows will still use one as and when it 'needs' to. Some idea of your hardware and program usage might help us envisage your I/O patterns and possible bottlenecks/workarounds.

When it comes to assessing maximum memory usage when opening large numbers of tabs at the same time, I rely on Peak Working Set to give me the absolute limit of memory used.

I think maybe the Chrome devs mean that 'shareable' is only with other instances of chrome.exe.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 22409
Joined: Sun, 28 Aug 2011, 17:27
Location: 58.5°N 15.5°E
Contact:

Re: time frame for a better x64 browser?

Unread postby Moonchild » Thu, 14 Jun 2012, 16:56

"shareable" memory is memory shared by common processes in windows, like kernel modules (For example, system DLLs, such as Ntdll, Kernel32, Gdi32, and User32, share memory among all processes). It doesn't actually count towards the individual process memory usage.
It would be a Very Bad ThingTM if Windows didn't keep allocated memory spaces strictly separate.
I'm a bit rusty on the changes in terms used in the memory management of the different versions of Windows, but the column you should be most interested in would be the Private Working Set, which shows the amount of physical memory in kilobytes that is currently in use by the process that is not shared with other processes. This number provides you with a pretty accurate measure of the amount of memory that a particular application uses, and Pale Moon isn't likely to have any shared processes beyond system libraries (no other program will be using xul.dll or mozjs.dll etc that is in the Pale Moon install dir).
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

dabruro

Re: time frame for a better x64 browser?

Unread postby dabruro » Thu, 14 Jun 2012, 17:18

Moonchild wrote:"shareable" memory is memory shared by common processes in windows, like kernel modules (For example, system DLLs, such as Ntdll, Kernel32, Gdi32, and User32, share memory among all processes). It doesn't actually count towards the individual process memory usage.
It would be a Very Bad ThingTM if Windows didn't keep allocated memory spaces strictly separate.
I'm a bit rusty on the changes in terms used in the memory management of the different versions of Windows, but the column you should be most interested in would be the Private Working Set, which shows the amount of physical memory in kilobytes that is currently in use by the process that is not shared with other processes. This number provides you with a pretty accurate measure of the amount of memory that a particular application uses, and Pale Moon isn't likely to have any shared processes beyond system libraries (no other program will be using xul.dll or mozjs.dll etc that is in the Pale Moon install dir).


I think you're confusing Shared working set with Shareable. Shareable simply means Not Private, i.e. other processes (system processes or others) *could* share it if they wanted to do so. Nonetheless, if it isn't in fact currently Shared by other processes, then it is being used solely by and for this process, and if this process exited then it would no longer be allocated at all. Private working set doesn't include shareable memory that's in fact being used by only this process. In my experience most user processes have only a fraction of their Shareable working set actually Shared by another process, so the amount they are using (amt that would become available if they exited) is in between the Private WS and the total WS but closer to the total WS. In this case the total WS is a better measure then the Private WS, though neither is exactly the right measure. Third party task managers (like Process Hacker) break it down better than the Win 7 task manager, and you can match it up exactly with one of the two numbers shown for all recognized browsers in Chrome's "about:memory".

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 22409
Joined: Sun, 28 Aug 2011, 17:27
Location: 58.5°N 15.5°E
Contact:

Re: time frame for a better x64 browser?

Unread postby Moonchild » Thu, 14 Jun 2012, 17:26

I'm not so sure about that, actually. I fired up process explorer for a breakdown, and it told me that of the 111MB of shareable memory, 72MB was in fact being shared with other processes, so the private working set is much closer to what is actually used by Pale Moon itself as a process. I wasn't saying that all of the shareable memory would in fact be shared by other processes, as the browser may be using some system libraries that are currently not used by other applications (e.g. I don't have any other hardware accelerated apps running at the moment), but that most memory is kept private by the browser. In fact, I'd have preferred if it didn't have to use the CLR libraries at all (like 3.6) but it can't be avoided in the NG version.
Attachments
ws-shareable.png
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

User avatar
satrow
Forum staff
Forum staff
Posts: 1703
Joined: Thu, 08 Sep 2011, 11:27

Re: time frame for a better x64 browser?

Unread postby satrow » Thu, 14 Jun 2012, 18:21

I'll add my screenshot for comparison (no, I didn't fire it up expressly, it runs on boot ;) ).

PMx64PExp.jpg

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 22409
Joined: Sun, 28 Aug 2011, 17:27
Location: 58.5°N 15.5°E
Contact:

Re: time frame for a better x64 browser?

Unread postby Moonchild » Thu, 14 Jun 2012, 18:56

Well, in any case, it means you can check with process explorer's "working set" and "shared ws" which seems to show you the actual ram usage for the individual process, looks like. and the Win7 resource monitor will keep you guessing ;)
Commit charge is at least the wrong thing to look at.

So actual process use would be Working Set - WS shared
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

dabruro

Re: time frame for a better x64 browser?

Unread postby dabruro » Thu, 14 Jun 2012, 19:26

Yep. Well, I'm off to install the other PM so I can switch between 64 and 32 bits at will :-)

BTW, for those who *really* can't afford the memory, v3 still uses just a fraction of the memory of current versions.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 22409
Joined: Sun, 28 Aug 2011, 17:27
Location: 58.5°N 15.5°E
Contact:

Re: time frame for a better x64 browser?

Unread postby Moonchild » Thu, 14 Jun 2012, 19:33

dabruro wrote:BTW, for those who *really* can't afford the memory, v3 still uses just a fraction of the memory of current versions.

Why do you think it's still supported here? ;)
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

dabruro

Re: time frame for a better x64 browser?

Unread postby dabruro » Thu, 14 Jun 2012, 19:38

Moonchild wrote:
dabruro wrote:BTW, for those who *really* can't afford the memory, v3 still uses just a fraction of the memory of current versions.

Why do you think it's still supported here? ;)

Yes, but is it supported to the extent that, if a critical security vulnerability is found in it, and Mozilla doesn't offer a patch from upstream since it's EOL, you'll patch it yourselves? On the Linux side, for example, Debian and/or Ubuntu state that they can't support it in their stable distro if it isn't patched upstream and recommends upgrading to a backport of v10 or higher.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 22409
Joined: Sun, 28 Aug 2011, 17:27
Location: 58.5°N 15.5°E
Contact:

Re: time frame for a better x64 browser?

Unread postby Moonchild » Thu, 14 Jun 2012, 20:23

dabruro wrote:Yes, but is it supported to the extent that, if a critical security vulnerability is found in it, and Mozilla doesn't offer a patch from upstream since it's EOL, you'll patch it yourselves? On the Linux side, for example, Debian and/or Ubuntu state that they can't support it in their stable distro if it isn't patched upstream and recommends upgrading to a backport of v10 or higher.

Yes it is. I keep a close eye on critical vulnerabilities that would apply to the gecko 1.9.2 branch and backport them. I have done so in the past and will continue to do so for as long as I support the legacy version.
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

dabruro

Re: time frame for a better x64 browser?

Unread postby dabruro » Thu, 14 Jun 2012, 21:08

Cool -- more people should know this! Assuming you're not interested in building for other platforms, someone else should do so based on your source patches. For example the people who work on some of the Linux distros... especially since some (e.g. Puppy or Lubuntu) are designed to work with very low memory so v3 is ideal...

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 22409
Joined: Sun, 28 Aug 2011, 17:27
Location: 58.5°N 15.5°E
Contact:

Re: time frame for a better x64 browser?

Unread postby Moonchild » Fri, 15 Jun 2012, 00:23

Well, I only check the patches that are relevant to Pale Moon's platform - I'm not looking at Linux or Mac bugs for it since they are N/A - any people doing that should check themselves and backport themselves.
Improving Mozilla code: You know you're on the right track with code changes when you spend the majority of your time deleting code.

"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne

dabruro

Re: time frame for a better x64 browser?

Unread postby dabruro » Fri, 15 Jun 2012, 17:28

Okay, I was assuming that most of the bugs are platform-independent, but maybe that's not true.


Return to “General support”

Who is online

Users browsing this forum: back2themoon, pmBill and 20 guests