Brian Nitz wrote:
> The intended scope is "JDS" which does include firefox and 
> staroffice.  But the original optimization configuation settings for 
> JDS2 were focused on components of the base GNOME desktop.  So more 
> work will need to be done.  Do you have any suggestions for firefox?  
> Turn off flash animations? reduce the default cache size?  
> Configuration settings don't exist for all of these and some that do 
> exist aren't yet available to the Java Desktop Configuration Manager.

I don't think config settings exist yet which would be interesting here 
- the work has to happen in the firefox community first.  My first vote 
would be for firefox to do less aggressive retention of pixmaps for 
non-visible pages (e.g. pages "Back" in the URL history several steps, 
and possibly hidden tabs).  This could have a profound effect on the 
memory footprint of the X server, which is one of the biggest culprits 
in desktop resource consumption.  Perhaps we could have a multi-level 
setting (e.g. 1-5) where one extreme is what we have today, maybe the 
next level is to free up pixmaps which are at least 5 steps back in 
history (I don't know where the limit is today, and am guessing its 
higher than this), and finally maybe the other extreme might be 
non-visible tabs and any history.  Or maybe an idle timeout could be 
applied (but beware of chewing up CPU in order to save resources ;-).

I wouldn't recommend anything heavy-handed like disabling flash 
animations unless it was simply influencing a default that the user 
could override if they chose to do so (in a fairly obvious way). We 
don't want to limit function (unless we have a very extreme 
circumstance, and I'm not convinced flash is so bad that one or two 
people can't use it now and then), we only want to reduce impact.

Simple stuff could be done right off the bat.  I think I still see 
staroffice doing spin loops. That's bad citizenship.  Everything should 
be done off of timers or events of some sort so that the CPU can be shared.

A bit OT: I'd love to see JDS pick up and refine xautolock 
http://freshmeat.net/projects/xautolock/ so that it's a good multi-user 
citizen (i.e. remove spin loops).  We have many customers who would like 
to have a desktop session terminate if it's been idle for a certain 
period of time. That's about maximizing desktop resource utilization 
also, but on an aggregate server basis vs an individual desktop basis.

-Bob

Disclaimer: Opinions expressed in this mail are my own,
and are not necessarily shared by my employer

> I intend to gather Sun Ray performance enhancement requests which are 
> not yet configurable into a proposal for the "Gnome lite" project.
>
> Bob Doolittle wrote:
>> Hi Brian,
>>
>> First off - kudos for dusting off the perf doc and making it current.
>> That'll be a big help to folks.
>>
>> Comment inline:
>>
>> Brian Nitz wrote:
>>>>> And even better if that configuration were visible and could be 
>>>>> leveraged
>>>>> by higher-level apps :-)     
>>>> I agree.  It might be helpful if we talked through how we think this
>>>> should work.  
>>> Most if not all of the performance related gconf keys are now 
>>> exposed via Sun Java Desktop System Configuration manager (was 
>>> APOC).   This document 
>>> (http://www.sun.com/bigadmin/content/submitted/jds_optimize.html) 
>>> was written for JDS2 linux, but the changes necessary to make these 
>>> policies work went into the codebase for JDS3 on Solaris 10.
>>
>> Since "JDS" encompasses some pretty pertinent higher-level apps,
>> as well as the desktop, I wonder what scope you're describing here?
>> When you say "changes necessary to make these policies work"
>> are you suggesting that firefox (for example) is now looking at
>> these keys and changing its behavior?
>>
>> That's the sort of thing I was imagining with my comment, but
>> I'd be (very pleasantly! :-) ) surprised to hear that such work has
>> already been done.
>>
>> -Bob
>>
>


Reply via email to