Speed up xubuntu by using more memory?

[Matías Szeftel]

I believe there's a tool called ooprelink

I think you can run it if you have prelink, but i m not sure, since i'm
not in my xubuntu box.

anyway try /usr/bin/ooprelink and see if it works.

Eero Tamminen escribió:
> Hi,
>
> On Friday 15 September 2006 15:30, Jelle de Jong wrote:
>   
>> I heard somewhere that big linux programs have to load and calculate and
>> create links to library's every time they start. This is one of the
>> reasons why openoffice is so slow.
>>
>> If it is possible to create a system that pre calculate these links and
>> put them in a table that is loaded in the memory. It could be possible
>> to speed up almost al linux programs especially the big ones.
>>     
>
> That's prelink. What it does: it checks each (dynamic library) dependency
> for a given binary, resolves the dynamically resolved symbols (like dynamic
> linker does normally at run time when binary is loaded) and stores the
> resolved addresses back to the binary on disk (to different section than the
> symbol table I think).
>
> If you update any of the binary dependencies, this prelinking needs to
> be redone (dynamic linker will automatically skip the prelink information
> if it's out of date).  You could add an apt-hook that (re-)does prelinking
> when things are updated.
>
> Besides improving application startup-time, prelinking will also save some
> RAM because prelink information is read-only (i.e. can be discarded when 
> memory is low and read back from disk if needed again) whereas run-time
> resolved symbol addresses are naturally private to the process (i.e. can be
> only written to swap when memory is low).  With a large number of large
> (C++) library dependencies, the amount of memory needed for resolved symbols
> can amount to several megabytes...
>
> So, prelink will help if you:
> - Have applications that link a lot of libraries: ldd <binary>|wc -l
>   (several dozens)
> - Those libraries export a lot of symbols: readelf -r <library>|wc -l
>   (thousands)
> - are also running low on memory
>
> Note that many of the applications, such as OpenOffice use dlopen() to load
> parts of their functionality (plugins...) on-demand.  Because these
> libraries cannot be known at linking/startup time, they cannot be given
> fixed address and therefore won't be prelinked although rest/most of the
> app would.  Michael Meeks (see Gnome performance-list) has some dynamic
> linker / C-library patches to improve this, but they haven't been accepted
> upstream (yet).  He has posted also some statistics about the performance
> and memory usage impact of symbol resolving to perf list and his blog.
>
>
> 	- Eero
>
>   


	
	
		
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya! 
http://www.yahoo.com.ar/respuestas