Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


On 04/11/2012 11:10 AM, Enrico Weigelt wrote:
does anybody has some knowledge about LO's memory usage increase
comparing 32 to 64 bit ? (heap data, not code).

I've seen a massive memory consumption increase on Chromium since
moved from 32bit to 64bit userland. Seems they quite frequently
used plain int types which of course gets doubled in size then.

"plain int" stays 32 bits in the LP64 model (where only long int and pointers go 64 bits), so the main increase in memory consumption is typically due to the larger pointers.

In general, the main motivation to switch an application from 32 to 64 bit on a platform that would support executing either (which is true at least for all the x86/x86_64 based Linux, Mac OS X, Windows) should be a demand for a large number of threads per process (as the need to allocate stack space for them easily conflicts with a small address space; but LO is not in need here, I'd say) or removal of legacy 32 bit versions of libraries from the system (as apparently happens on Mac, e.g. with in-process JVM). Or, esp. on x86/x86_64 architectures, improved application performance due to the larger register set (which needs to be judged against the larger pointer size, as there is no process model for x86_64 with 32 bit addresses).

Anyway, the trend apparently is to go 64 bit regardless.

Stephan

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.