=== bjf is now known as bjf-afk [00:26] * rickspencer3 braces for $sudo apt-get dist-upgrade tonight [00:27] rickspencer3, have you not gone lucid yet? [00:28] robert_ancell, not yet [00:28] but tonight [00:29] rickspencer3: Should be fun [00:30] I hope your computer doesn't have an accelerometer [00:31] Xorg decided my accelerometer was a joystick so when I'd bump my desk or press on the keyboard it'd cause it to move a little which would move my mouse to the center of the screen [00:31] was good times [00:31] hehe [00:31] I will be upgrading my desktop first, so should be ok [00:32] Once I figured it out it was pretty awesome, actually [00:32] I picked my laptop up and moved it around to open a terminal and turn it off :) [00:33] hehe [00:36] Amaranth: what was the button click? [00:36] * Keybuk has images of Amaranth slamming his laptop onto the floor to click on things [00:36] Keybuk: Probably dropping the laptop but I just used the mouse for that :P [00:36] you know what this means? [00:36] X HAS HOT-PLUGGABLE ACCELEROMETERS! [00:37] * Keybuk images the possibilities [00:37] ...err...possibility [00:37] ...err... [00:37] heh [00:41] damnit [00:41] I just realised why this kernel build is taking forever [00:41] forgot to comment out the additional flavours [00:42] building 5 kernels is always fun [00:44] I had to turn my heating off :p [00:44] Keybuk, is that kernel build going to make the desktop come up faster? [00:44] hehe [00:44] rickspencer3: it includes a patch to the i915 KMS driver [00:44] we're down to 11.82s [00:44] rickspencer3: I saw [00:45] chip chip chip [00:45] rickspencer3: I love the fact that a quick bug fix to the X package got it within budget [00:45] rickspencer3: based on previous experience I think my compiz packaging changes will drop that down to 11 [00:45] I don't think tjaalton even realised it was a performance problem [00:45] though that being said [00:45] xkbcomp caching isn't working [00:45] so X may get even faster again [00:45] If X gets under budget we could use some of that time :) [00:45] Amaranth, thank you :) [00:46] rickspencer3: but seb128 doesn't seem to want me to do it the way I am [00:46] hmm [00:46] so I'll have to have ugly package names like compiz-plugins-universe [00:47] usually turns out seb128 is right ;) [00:47] Well I want to add about 70 new binary packages (one for each plugin) instead of just splitting things into "stuff we use" and "stuff we don't use" [00:47] hmm [00:48] s'lot [00:48] 70 binary packages feels bad ;) [00:48] without knowing anything ;) [00:48] we have a lot of plugins :) [00:48] actually it'd be 54 new binary packages [00:48] yeah. but maybe packages is not the right mechanism to split them up on a one-by-one base [00:48] since I wouldn't split the compiz-fusion-plugins-extra package [00:48] what would we gain by such a split? [00:49] well the main goal is to not install plugins we don't use [00:49] e.g. how does that reflect on user experience? [00:49] but I figured why I was in there I could make it possible for users to only install the plugins they actually use as well [00:49] why not? disk usage (unlikely) startup time due to unneeded loading? [00:49] (why not ship not used plugins) [00:49] asac, compiz only loads the plugins in use? [00:49] i dont know [00:49] ;) [00:50] well not installing compiz-fusion-plugins-extra cut 0.5 seconds off login time [00:50] i want to understand the motiviation. maybe it loads everything on startup and just disregards what is not used (this would indicate that not installing it might help in time consumptioN) [00:50] what happens if you link all the plugins into compiz itself? [00:50] so instead of loading 1,461,395 .so files [00:50] compiz stats at least the .so and the .xml file and libcompizconfig (and thus compiz via the ccp plugin) loads the information for _every_ installed plugin [00:50] it just has them all built in? [00:50] Keybuk: I was thinking about that, actually [00:51] link at least some of them directly to compiz and hack it so when it tries to load those plugins it just dlopens itself [00:51] no [00:51] no dlopen [00:52] link them directly to compiz with an array of structures [00:52] we already dlopen and I don't want to hack that much :P [00:52] which have function pointers [00:52] that's my whole point you numpty [00:52] dlopen() is slow [00:52] the relocations caused by dlopen() are slow [00:52] I was talking to get rid of the IO [00:52] dlopen is slow for already loaded stuff even? [00:52] there is no I/O [00:52] asac: yes, because you still relocate [00:52] hrm [00:52] * Keybuk sees nothing but CPU [00:52] hmm. thought some scope might just fail quick saying "already loaded" [00:52] I see a little IO on mine [00:52] and I would bet money that at least some of that is the overhead of dlopen()ing everything [00:53] rather than just having them builtin with an array of structures [00:53] instead of doing all the actual linking etc. [00:53] oh, that reminds me, we're screwing up huge with compiz right now [00:53] also adding so many packages kicks our already slow packaging index a bit further [00:53] the first time compiz is loaded the ccp plugin loads the XML files and writes out protobuf versions which it can then use instead [00:53] they load a lot faster [00:54] but I'm pretty sure we don't generate those for the .deb so when you guys bootchart the first boot after install... [00:54] where does it load that to atm? user home? [00:54] protobuf that is [00:55] asac: yeah, ~/.cache/compizconfig/ [00:56] much less CPU time to parse protobuf vs XML (especially since it uses XPath) [00:56] so can that be pregenerated in a system location? [00:56] would that be useful? or does that need to be regenned because of user settings anyway? [00:57] although in the bootcharts by the time you see it spawn compiz-decorator all plugins and settings are initialized and most of the CPU usage is after that [00:57] asac: It only needs to change when the xml file changes [00:57] those are system xml files? [00:57] right [00:57] e.g. could be done by a trigger or update-compiz-stuff in postinst? [00:57] the user settings are in gconf [00:57] it could, yes [00:58] ok. but changing those user settings would also require a full cache regen? [00:58] in .cache... ? [00:58] but then compiz would build-dep on libcompizconfig [00:58] no, changing user settings has nothing to do with the xml or protobuf files [00:58] ok [00:58] how much time would you think will those protobuf files save? [00:58] is that worth the effort? [00:58] dunno [00:58] ;) [00:59] I'd need to do a clean install of lucid then two boots [00:59] what state do they remember? [00:59] the protobuf files hold exactly the same information as the xml files [00:59] so you still need to open .so's to decide whether you want that loaded or not? [00:59] so plugin dependencies, options, descriptions of the plugins and the options [00:59] plugins [01:00] bleh, I bet that's why removing compiz-fusion-plugins-extra saved so much time [01:01] asac: no, compiz should just be loading the core.xml file and the plugins and xml files for plugins specified on the command line then ccp tells it what the active_plugins setting is and it loads those plugins and xml files [01:02] but compiz can also tell you what plugins are enabled and I'm pretty sure it checks that on startup by stat'ing everything in /usr/lib/compiz... [01:02] s/enabled/installed/ [01:03] hmm [01:03] stating or dlopening? [01:04] Amaranth: ? [01:04] just stat, iirc [01:04] that should be quite quick. if its just a timestamp compare [01:04] at least i dont have a zilions of files there ;) [01:04] so the xml files parsing would be saved by doing the caching? [01:06] ok, it doesn't stat all the plugins unless you ask it to via dbus so that isn't a problem [01:06] so the main thing is going to be core reading the XML files (required) and not having the protobuf cache for libcompizconfig [01:07] right. and the protobuf saves us from doing more parsing? [01:08] but at least on my latest bootchart almost all the CPU usage is _after_ compiz-decorator is started which means at that point compiz has initialized all the plugins and loaded all of their settings from gconf [01:08] so the only way to know if there is any win at all is to try it [01:08] yeah. probably [01:08] so I need a clean lucid install and bootcharts for the first boot and the second boot [01:09] I have no idea how people are producing bootcharts for their mini 10v systems though [01:09] If the first boot already has bootchart and that is being used this could be a win [01:09] if not, we've already got the protobuf files [01:10] but that does seem to prove dlopen isn't hurting at all unlike what Keybuk was saying [01:11] I produce lots of bootcharts for mini10vs [01:11] what charts would you like? [01:11] Keybuk: When you do the daily bootcharts is that automated? [01:11] yes [01:11] If so, is that the very first boot into the installed system? [01:12] second boot [01:12] Ok, so now I'm lost [01:12] what would you like to know? [01:12] What the heck compiz is doing using so much CPU _after_ it has loaded all of the plugins and their configuration :) [01:13] I suspect printf() will be your friend [01:13] If you look on your bootchart all the compiz CPU usage is after compiz-decorator starts but that doesn't start until compiz is "finished" loading [01:14] some deferred work in the main loop perhaps? [01:14] an idle timer function? [01:14] I don't think we even have those [01:14] http://people.canonical.com/~scott/tmp/max-lucid-20091209-1.png [01:14] wow that's a very long chart [01:14] that's a "first boot" chart of alpha 1 [01:14] http://people.canonical.com/~scott/tmp/max-lucid-20091209-2.png [01:14] that's the "second boot" chart [01:15] (the second boot charts are the ones that get published on daily-bootcharts) [01:15] Amaranth: mine are longer than most people's ... I don't like to brag [01:15] heh, what is up with udevd there? [01:15] nothing [01:16] bootchart normally condenses things a bit [01:16] ok on your charts compiz is showing a lot of CPU usage before compiz-decorator loads too [01:16] hides a lot of the detail [01:16] but most of it is still after [01:16] when I generate them myself, I tell it not to do that, so I get all of the processes and detail [01:16] they're less easy to read, but have more information [01:17] Amaranth: so what I'd do is start sticking printfs throughout compiz [01:17] this is going to suck :P [01:17] grab the kernel uptime clock and put that at the front [01:17] (or just write to the kmsg device) [01:17] then you'll have numbers that tell you how far into the boot it was doing what [01:19] oh, it looks like robert-ancell already did all of this [01:19] there is a nice 090_profiling patch in compiz that just needs a build flag to enable [01:20] a nice patch which I broke with my changes, whee [01:30] don't you just hate that [01:30] gcc has stuff to add profiling hooks to functions too [01:30] that's quite handy [01:30] you build your source with extra flags [01:30] and LD_PRELOAD in a hook library when you run it [01:31] your hook gets called for every function call [01:31] so you can instrument it [01:32] neat [01:33] if I'm reading this correctly even with a warm cache and already logged in compiz takes 2.14 seconds to load :/ [01:34] takes 0.01 seconds to load and parse the core.xml file, not as bad as I thought [01:35] 0.06 seconds to load our "required" plugins (ccp, move, resize, decoration, place) [01:35] oh, and crap [01:36] it loads the settings for each plugin as it loads the plugin (duh) so we've only loaded those 5 plugins when compiz-decorator starts [01:37] I'll have to check this on boot but it looks like loading most of the plugins is "free" [01:37] except of course for the ones we absolutely want to have (wall, animation, commands, etc) [01:37] brb, rebooting === eeejay_away is now known as eeejay [01:44] hmm, according to this compiz starts in about 0.6 seconds on boot [01:45] but 0.77 the second boot (with ureadahead that time) [01:45] hrm [01:45] on your bootchart? [01:46] no, with this profiling patch [01:46] I think you're getting too preoccupied with when compiz hits the main loop [01:46] it goes from startup to the first time eventLoop is idle [01:46] if it hits the main loop quickly, that's nice [01:46] it's still churning away [01:46] so whatever is eating all the CPU must be happening afterwards [01:46] and apparently compiz does have idle timers because all plugin loading happens in the eventLoop [01:47] so the first time it is idle that should mean it is done loading [01:47] it hits the first idle after it has loaded all of the plugins and their settings, anyway [01:48] so any further processing is within the plugins and the (most likely) unavoidable overhead of using compiz [01:51] at this point I'm thinking using metacity by default in lucid is going to be far less painful then trying to optimize the animation plugin [01:54] why is there any animation? [01:54] nothing is happening on screen [01:54] just a big window in front of everything with a bit of a throbber [01:54] Keybuk: the animation plugin does something with basically every X event [01:55] can we turn that plugin off until we're ready? :p [01:55] compiz sort of "flashes" when you enable/disable a plugin [01:55] so make the plugin start "off" [01:55] and don't hook into X until it's turned "on" [01:55] hmm, actually it doesn't seem to flash anymore [01:56] heck we could delay enabling every plugin except ccp, move, resize, place, and decoration if you want to go down that route [01:56] oh, and session [01:56] why do we even need those? [01:57] we have no windows to move, resize, place or decorate [01:57] just one big plymouth/xsplash window which was already in the right place anyway [01:57] well we need ccp, session, and decoration so we can put everything back where it was before (if you saved a session) === eeejay is now known as eeejay_away [01:57] the others are just the ones we force you to have enabled and the way we do that prevents us from doing any tricks with delayed loading [01:57] it doesn't need to get put back until after everything else is loaded surely? === eeejay_away is now known as eeejay [01:58] Do you want xsplash to go away _then_ have all of your windows gain a decoration and jump to the proper position? [01:59] no [01:59] just do it last [01:59] in one step [01:59] otherwise for the rest I guess I just need compiz to hook into the same thing xsplash does to know when to go away [02:00] of course now we're cheating and dumping all the CPU load right at the time the user is going to start trying to use the system... [02:01] no, just before [02:01] but I guess we do that with other things too [02:01] basically [02:01] right, it'll start happening while xsplash is doing the fade [02:01] if you're saying that CPU load is all compiz responding to things that are happening that the user can't see anyway [02:01] why not disable all that [02:02] and then, just before xsplash goes away, do it all in one great big lump [02:02] then take xsplash away [02:02] no [02:02] do it before xsplash fades [02:02] uh, how? [02:02] co-operate between the two [02:02] I'd like to point out compiz doesn't do dbus [02:02] xsplash tells compiz it's going to fade, and waits for compiz to say "I'm done" [02:02] that kind of thing [02:02] really? [02:02] * Keybuk spies a compiz dbus plugin [02:02] well, we have a dbus plugin but then we'd have to load a plugin :P [02:02] Yeah, I sort of wrote that plugin :P [02:03] you said loading plugins was free :p [02:03] and were blaming what the plugins did when nobody could see [02:03] all I'm pointing out is that there's a solution for any problem :D [02:03] well looking at the profiling the delta between loading that plugin and loading the next is 0.01 or so [02:03] sure but a solution that requires 10 hours of work is going to take a month for me to finish [02:04] that's cool [02:04] we have more than four [02:04] for now, adding sleep (10) into compiz startup would be a good way to find out if that was the problem? :p [02:04] if we make compiz start, init, then just sleep [02:05] see what happens [02:05] yeah, I could put that right before eventLoop, would be a great way of seeing if all of this is happening in the eventLoop anyway [02:06] if you throw me a deb (PPA is good) then I'll happily test it out on the mini [02:06] hrm, I really need another computer to run this stuff on [02:06] having to keep rebooting the one I'm on IRC with is lame [02:08] * Amaranth debates wiping out the computer people play games on [02:14] Keybuk: btw, that idea of linking plugins directly to compiz is starting to sound better and better [02:15] I've thought up a way to do it without getting too crazy and would still allow loading plugins the normal way [02:15] oh? :) [02:16] usual way is that each plugin has some kind of struct-o-function-pointers [02:16] which is what you find with dlopen() anyway [02:16] And we do, right [02:16] to build them in, you just have a script make a C file that turns those into an array [02:16] then for (plugin **p = builtin_plugins; p && *p; p++) [02:16] *p->init() [02:16] type thing [02:17] yep, will look at that this weekend [02:17] this is [02:17] exactly [02:17] how the kernel works ;) [02:17] if you =y, you get the same code (mostly) [02:18] then an auto-generated C file that has pointers to them all [02:18] of course if I also want to make compiz stop loading the XML for the plugins this could get somewhat more complicated [02:18] but XPath is apparently not as slow as I thought [02:18] Either way compiz in lucid is going to look nothing like upstream though :/ [02:19] but they do want to be able to compile plugins into core upstream as well so I suppose I could just port the stuff to the C++ code and submit it there once I'm done === eeejay is now known as eeejay_away === eeejay_away is now known as eeejay === eeejay is now known as eeejay_away === eeejay_away is now known as eeejay === eeejay is now known as eeejay_away === robbiew is now known as robbiew_ [05:21] hi. can u use the same image ud install from a cd, on a usb pendrive? [05:23] Omen_20, yes, use System>Administration>Startup Disk Creator [05:23] See also https://help.ubuntu.com/community/Installation/FromUSBStick [05:24] oh ok. so this makes an iso image usable from a pendrive? [05:24] yes [05:25] sweet. thanks! I hoped there was an easy way. CDs were starting to feel wasteful and now that im on break and have a TB drive I want to try out tons of stuff. [05:25] Omen_20, np, have fun! [05:26] :D [06:49] Good morning [06:53] Guten Morgen pitti [06:53] bonjour didrocks [07:29] morning pitti [07:32] hey glatzor [07:49] hello bryce, do you know how I could access the icon of a window from gtk? [07:49] bryce, the WM_ICON_NAME property doesn't seem to be handled very well by metacity [07:49] it is just the same as WM_NAME [07:54] Keybuk: what was a performance problem? [07:54] heya [08:36] good morning everyone [08:39] hello desktopers [08:41] hello seb128 [08:41] hey chrisccoulson [08:41] did you manage to sleep at all? ;-) [08:42] you seem to always be there :-p [08:42] seb128 - i slept for 3 hours :) [08:42] urg [08:43] you must be glad that tomorrow is saturday ;-) [08:43] i shall be brewing my coffee extra strong this morning [08:43] yeah, i'm glad that tomorrow is saturday ;) [08:43] salut seb128 [08:43] morning chrisccoulson [08:43] hey didrocks [08:43] hum, coffee, looks like a good idea indeed [08:44] hey didrocks [08:48] bonjour seb128, hey chrisccoulson [08:48] * pitti back from pm-utils debugging [08:48] good morning pitti [08:49] hey pitti [08:49] how are you? [08:51] pitti, btw not sure if you read log from night in the morning or not [08:52] pitti, the work item count for lucid is somewhat wrong [08:53] http://piware.de/workitems/desktop/lucid/report.html ? [08:53] seems fine to me [08:53] (no, I didn't see that bit) [08:54] pitti, somewhat around 1am hour time [08:54] if you have log [08:54] I do [08:54] basically some specs have alpha3 or beta1 wis [08:54] and those are on no count [08:54] right [08:55] that's a current limitation in the parser [08:58] hum, it should perhaps list anything in the "work item.*:" format as for lucid now? [08:58] right now we have tens of items not on the charts [08:59] so the trend and counts are somewhat biased [08:59] right [09:01] ok, let me look into that [09:02] thanks [09:06] pitti, btw while I'm a it review from the indicator package in new is welcome [09:06] I sponsored it for kenvandine yesterday [09:06] but I didn't want to source NEW since I uploaded [09:06] ok [09:07] thanks [09:08] * seb128 stops bothering pitti now [09:24] ah [09:25] it seems my phone was playing up when i went away for breakfast [09:25] hehe [09:25] * seb128 start looking at strace and http://people.canonical.com/~seb128/nautilus again now [09:26] excellent, that will probably keep you occupied for some time ;) [09:26] I wonder if we could reduce the number of stats on alternative paths [09:26] like /usr/local/... [09:26] and if that would make a difference [09:26] I guess stat calls are cheap usually [09:28] yeah, i'm not too sure [09:29] how come it needs to stat() user folders such as downloads and public when it starts? [09:29] if it's not displaying a window [09:29] anyway, time for me to grab another coffee:) [09:29] could comment [09:29] ups, "good comment" [09:33] grep stat nautilus.strace | grep ENO | wc -l -> 707 [09:33] 652 of those being for icons [09:34] I'm wondering if we could check for /usr/local/icons earlier and avoid stating each subdir [09:34] or /usr/local/share/icons rather [09:37] seb128 - so, it checks for subdirectories of /usr/local/share/icons before making sure that the parent directory exists? [09:38] 1420 14:24:08.630795 stat64("/usr/local/share/icons/hicolor/16x16/apps", 0xbfb17340) = -1 ENOENT (No such [09:38] file or directory) [09:38] 1420 14:24:08.631034 stat64("/usr/share/nautilus/icons/hicolor/16x16/apps", 0xbfb17340) = -1 ENOENT (No su [09:38] ch file or directory) [09:38] 1420 14:24:08.631357 stat64("/usr/local/share/icons/hicolor/16x16/categories", 0xbfb17340) = -1 ENOENT (No [09:38] such file or directory) [09:38] etc [09:38] etc [09:38] it does that for each dir from the index [09:40] vuntz - do you know what is happening about implementing a new shutdown API in consolekit, to unbreak the current situation in gnome-session with policykit-1? (i think i've asked you about this before). Do you know if anyone has offered to do the work in either consolekit or gnome-session yet? [09:40] seb128 - there seems like an opportunity for some optimisations there :) [09:41] yes [09:41] those stats are cheap though [09:41] like 1ms or less [09:41] but if we could spare some hundred calls... [09:41] 1ms each, or for all of them? [09:42] look at the lines I copied [09:42] it's like 0.3ms each [09:42] ah yes [09:43] I will start by looking at backgrounds and what you pointed about standard dirs [09:56] chrisccoulson: mccann is supposed to do the work in consolekit, and I'm supposed to do the work in gnome-session [09:56] chrisccoulson: but if you want to help, that would certainly be welcome! [09:57] chrisccoulson: https://bugs.freedesktop.org/show_bug.cgi?id=24493 [09:57] Freedesktop bug 24493 in Daemon "a better shutdown api" [Normal,New] [09:57] vuntz - yeah, i was thinking of helping:) [10:00] seb128: http://piware.de/workitems/desktop/lucid/report.html [10:00] seems more realistic now [10:00] * pitti fixes the y steps [10:00] pitti, you rock [10:01] I updpated the howto, I'll mail an announcement [10:01] since the semantics now slightly changed [10:01] asac: ^ this should address your concern from a week ago, too [10:01] pitti, thanks! [10:32] seb128, for system call performance you might be interested by systemtap [10:32] ie benching open, read, ... [10:33] baptistemm, did you ever use it? [10:34]