Emmanuel, Thanks for the great response I think I have a better understanding of the issue now.
I'm still a little confused as to why the move to lgi was considered to be necessary at all. From an end user perspective, the benefits to lgi are not obvious. Although I prefer the new configuration api changes. And being able to run certain cairo based plugins like blingbling without needing oocairo etc. These benefits seem minor when compared to the ~10% cpu consumption at idle from awesome. In a 24hour period it by far takes more cpu time than any other app, including some hungry ones, like adobe flash, or X. I presume all of these X11 round trip calls and blocking issues existed in 3.4 branch for some time, but what does 3.4 do / utilize that is so much more efficient that lgi does not? Is it truely impossible to retain the new layout functionality and revive, if not in part some older 3.4 components? I wouldn't mind contributing here, but I don't know much about X api (except its supposedly a nightmare) so not sure how useful I would be. Thanks again, Harvey On 03/29/2014 12:07 AM, Elv1313 . wrote: > Hi Harvey, > > The answer is not black and white, and we are definitely aware of the > issue. The high CPU usage is due to many different thing. Up to > ~October, before LGI added support for caching, it was the main > bottleneck by far. But the reason it was a bottleneck is also partly > because we abused it quite hard. I may have the worst config imaginable > in term of CPU intensive bloat, but as far as I know I am the only one > who took time to gather metrics so here goes nothing. A single tag > change called LGI 600000 time. The reason for that is that many Awesome > operations are not optimized properly. For example, repainting a single > widget can needlessly induce the repainting of many, if not all of them. > Other operations also require expensive X11 round trips and waiting. > Then, some I/O operations that could be cached are not. While not an > issue directly, it become one is the system has high IOwait ratios. > > The CPU usage probably wont ever reach 3.4.* level again. The LGI > overhead can be lowered, but not eliminated. Then, the new layout system > offer much greater flexibility and features no one in his right mind > would like to revert. That being said, there is room for improvement and > we really want to fill that room ;). Then again, Awesome is open source, > so patches are welcome. Each of us has there own priorities and agenda. > Mine is to make Awesome more powerful and competitive against modern > desktop shells ( https://github.com/Elv13/radical ) others have even > more useful goals, such as fixing bugs and making users happy :P. So, in > the end, as of now, anybody with a Core2Duo or even first generation AMD > Athlon X2 for a decade ago should not feel any slowdown, that includes > me with my bloated config. The main reasons why Awesome can be slow is > users calling blocking functions or shell commands from rc.lua, not the > ~5% CPU usage awesome can sometime take. This is what lock awesome for a > few milliseconds. Awesome 3.5.2 introduce fit() caching, Awesome 3.5.3 > will introduce a few more micro optimizations. If you are willing to > help, then attacking one or more of the issues mentioned above would be > more than welcome. > > But first, be sure to try with both LGI git and Awesome git, maybe some > of the optimizations will lower the CPU usage under what you call > acceptable. > > > Best regards, > Emmanuel (Elv13) > On 28 March 2014 23:45, Harvey <[email protected] > <mailto:[email protected]>> wrote: > > Well, > > Just bumped myself finally from 3.4.15 to 3.5.2.. and although my > machine is fast so I don't visually notice anything, awesome does take > up allot more cpu the before.. While googling about it I noticed several > speculations that this had something to do with lgi, and was not an > awesome-wm issue. But it all seems like speculation... > Was wondering if anyone had any kind of concrete conclusions here? > > Also there are several CLOSED bug reports of this issue, with no > explanation on their closure or conclusions / resolutions offered for > this issue.... > > It is certainly not reasonable to just not use widgets (which doesn't > resolve the issue) > > Is awesome right now just planning to ignore this until lgi gets better? > Or is there something else here (an issue within awesome?) > > I'm going to try and run the latest git repo copy and see if the issue > persists.. otherwise I guess I'm going to roll back to 3.4.15 :/ > unfortunately. any input? > > Thanks! > > FYI lgi-0.7 and lua-5.1 on gentoo > > > -- > To unsubscribe, send mail to [email protected] > <mailto:[email protected]>. > > -- To unsubscribe, send mail to [email protected].
