Re: update: Re: [dwm] recent changes to dwm (since dwm-3.5)

|The motivation is reducing the code, grouping the functions into |more intuitive sets and reducing the amount of exported |functions (only because several functions have been called from |a different object in one place - that was really annoying). |So all in all this also reduces the call graph and makes the |executable slightly smaller than before. Beside the fact of the |new Layout struct being ready for more layout-specific |additions. Could I just see if it's possible for mainline to just not mark drawtext as not static? (I'm looking to see if there's a simpler way of re-instituting per-window titles than Ross Mohn's patch - which is very impressive but looks to me like a huge pain to maintain - which inherently involves both writing strings and traversing the client list so having both sets of functions static means more patching. I'd image Ross's titles patch would also be slightly shorter without having to un-static this.) Does the slight change in executable size from making them static actually remotely matter? I work with images/databases and the resident code size is almost always a vanishing fraction of the data-structure memory usage. For example, on my x86-64 machine sizeof(Client) is 408 bytes, of which 256 is the title array. Given that the majority of applications don't change title remotely frequently I've wondered about the tradeoff in making that a malloced array. Of course client list traversals in dwm is going to be nowhere near as cache hot as application code - and the cache ought to map only those fields actually used at during the traversals in layout algorithm - but if you want to optimise something I'd suggest data structure size is more practically relevant than executable size. cheers, dave tweed ___________________________________________________________ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
Received on Tue Feb 20 2007 - 12:08:58 UTC