562519 - cache result from PR_GetPhysicalMemorySize

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[timeless]

Most systems I've dealt with don't employ 'hot-memory add', as a result each additional call to PR_GetPhysicalMemorySize is incredibly expensive for what is generally a useless operation. Technically w2k3 svr, Solaris 7+ and in theory Linux support how-memory add.

An engineer at Nokia reported that during profiling of browsing with gecko1.9.2:
> According to strace there are up to 15 opens for /proc/meminfo file per second.
...
1517  10:32:27.240142 open("/proc/meminfo", O_RDONLY) = 45                     
                                                        ...
1517  10:32:31.314422 open("/proc/meminfo", O_RDONLY) = 45

For Gecko on the n900, the amount of physical memory will never change and certainly not at runtime.

per bug 560090 comment 3, NSPR is uninterested in offering a caching version of this function.

while I could call xpcom to get this information, I think the overhead of calling xpcom isn't worth the space savings for the statics i'm adding here.

Comment 1

[timeless]

Attachment: proposal

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 442262 [details] [diff] [review]
proposal

-  PRUint64 size = PR_GetPhysicalMemorySize();
+  static PRUint64 size;
+  if (!size) {
+    size = PR_GetPhysicalMemorySize();

Why didn't you just add "static" to the variable, i.e.:

static PRUint64 size = PR_GetPhysicalMemorySize();

Comment 3

[timeless]

Attachment: static calls

Comment 4

[Daniel Holbert [:dholbert]]

http://hg.mozilla.org/mozilla-central/rev/6e24e819f1ed