[Motorola Droid RAZR] Ohmster:
[MENTION=240993]casper[/MENTION], I forgot to mention that your new avatar is very nice and it sure beats looking at "Bart Simpson" and hoping the individual I am talking to has some measurable level of maturity and skill instead of the typical Simpson "Doh!", haphazard approach to life in general. LOL! :laugh: You are a very handsome and intelligent man, Casper.

[MENTION=3687397]parser[/MENTION], [MENTION=240993]casper[/MENTION], & [MENTION=1807728]brkahughes[/MENTION], thanks for the feedback. Being a part of a larger groups allows us to tackle issues that we cannot solve alone.

I am not saying you are incorrect or that Xposed Modules cannot slow down the device. They can and they do. But I want to examine this a little further. 30 years as an electronic technician have forced me to be reserved in my judgement until all the facts are in. I am also guilty from time to time of "green lighting" a build, app, or xposed module before it was thoroughly vetted and tested and I learned from it. :)

Please read and review this link:

Does Xposed slow down the phone?

...Xposed Frameworks and it's Module Children could very well indeed impact system performance. In my pursuit for better and better system monitor apps and modules, some of the modules hit the system like a club, contributing more to the lag and decrease in performance than if they were not there at all. Modules like CoolTool and Android Tuner Pro gave greats stats with graphs, bar meters, timelines, and badges, but it took so much power to not only create the UI for them, but to cull the data in close to real time to be of any use. They had to go. The only Xposed Module I found so far that has so little impact on the system to be "non existent" is CPUFreq in Statusbar because it does not draw it's own UI nor does it cull it's own data. It reads the already present in the system file, which you can check yourself by running this command in a terminal window:

#cat "/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq"

There you go, the current CPU frequency at the moment the file was read and output to the screen. It does not take much to get this data, you can do it with a single command. The module itself is only a timer that repeats this "cat command" once each second and instead of outputting the file contents to terminal screen, it outputs to the statusbar. I don't think this particular module is responsible for slowing down the system.

Our CPUs are dual core and can execute ONE function, 1.2 million times each second.

Maybe the module takes 10-25 slices of time to perform it's job, but what is 20 out of 1.2 million slices every second? How about the other modules, how about the Xposed Framework itself? I don't know enough about the code used to produce the Xposed Framework but it uses kernel resources already present to allow it's children (Modules) access to the system. I don't believe the framework itself affects system performance, but the child modules are a different story. CoolTool and [URL="https://play.google.com/store/apps/details?id=ccc71.at.free&hl=en"]Android Tuner Pro[/URL]

both

tax the system heavily.

So what about the other modules? CPUFreq in statusbar gets a thumbs up from me. Greenify? OMG, my system would slow to a crawl without the ability to force things like Facebook to sleep. The "Dress Up Modules" like Ex-Themer[KK], GravityBox [KK], Advanced Power Menu, and too many to list could ALL slow down the system with the jobs that they do. Some experienced members do not use Exposed Modules at all. Many agree that Greenify is essential. I will tell you what, right now on build 10/23, I don't have this serious lag issue at all. We need a procedure to debug the Xposed Framework and child Modules.

Debugging Procedure for Xposed Modules

But when I update and see this condition return, I will disable the Xposed Framework which will disable ALL of the modules as a test to see if the performance returns and if the lag clears up. If it

does not

, we can rule out Xposed Modules as the culprit. If disabling the Xposed Framework

does

speed up the system and clear screen lags, Then I can enable it again and uncheck all modules to disable them, and restore them one at a time in an effort to identify the culpable modules. That is a

LOT

of work. Every change requires a complete reboot and some run time to see what, if any change occurs. I currently run 12 Xposed Modules and a reboot for each one, plus at least 6 hours run time per module disabled, will add up to a very long time troubleshooting. It often takes a day for the lag to show up. One module a day is 12 days non-stop troubleshooting and a new build update can "make the issue go away". Can I do all this at once in one build, I don't know but it is a starting point.

You guys now have the debugging procedure outlined, by all means, feel free to contribute your own results to the group.

And let's not forget, many of the builds do not display this issue at all. Thus the Xposed Framework and it's child modules may or may not be a contributing factor. But I doubt it is the entire cause of the issue at hand. Exposed Framework is not a wacky app that some people are trying out, it is a tested and proven extension of the Android kernel to access many system services that we could not do at all without such intimate access to the kernel itself.

Yes, lag and poor performance could be attributed to some bad modules. And it could also be that some modules aggravate a poorly coded build update, many of which are optimized afterwards and are available in a subsequent build release. We won't know until we test it further. Thank you all for your time, patience, and

if you actually read and understand all of this, your contribution posts

. ;) :good:

P.S.

You guys and gals all ROCK! All of you are a very dedicated group of individuals, scattered all around the world, and come together, in concert, to find and fix issues with our current cm11 build releases. Everyone is friendly, courteous, and helpful to each other in this group and make each other feel welcome and appreciated, even the newbies. And even the senior members are now becoming a little more generous with their Thanks tokens. This is a very fine group of people and I am very proud to be one of you! :highfive:

P.P.S.

[MENTION=5241993]sad days[/MENTION] has finally made a post to the Q&A thread and he is 5 posts short of being able to post in this developer thread. For those of you who wish to finally say thanks for his support, go to the Q&A thread, make him feel welcome, and allow him to get the 5 additional posts he needs to post in this forum. The guy/girl is a one heck of a terrific moral booster for the group and should be shown some of the appreciation he has given almost every single person in this thread. :D