[OnePlus 6T  ROMs, Kernels, Recoveries, & Other Dev] Mostafa Wael:
Lengthy not-so-boring Analysis 2

Greetings everyone! Hope you're doing well and enjoying your experience with RenderZenith kernel as much as I do. I just thought of sharing my latest insights with you and maybe answer some of the questions some of you might have thought of. As I said earlier in this post here, I came to the conclusion that the default settings seem to provide the best balance between performance and battery consumption. However, I had the ambition to further extend the battery life we can get on the OP6 with this kernel. Going through the settings, I stumbled across the top-app schedtune.boost value, where it was set to 5 for all the time. This sounded a bit like an overkill, especially when you consider the fact that when setting schedtune.boost to a positive value greater than zero the tasks will be iterated initially on the bog cluster. Knowing how power-consuming the big cluster on the OnePlus 6 can be, I decided to set it to 0, set the schedtune.sched_boost to 5 (so that the schedtune.boost gets boosted during any interaction and not drop midway) and give it a spin. Here is a link to the updated stats: https://docs.google.com/spreadsheets/d/1TH0nR3i-VAKVpTHZDn5LsCFdjQrj0pIWqub5zxFhFNE/edit?usp=sharing

(You can find the profile written in a note as indicated in the spreadsheet in cell A8)

As you can see, this setup has further improved the battery life by an additional ~0.5%/h, which is not an insignificant difference at all. It is also worth noting that I could reach an active drain rate sometimes as low as 9.65%/h on some days. Which brings us to a very important point; with this setup, there is a slight inconsistency in battery life. It's not always better than the previous default profile, but during my testing, it was never worse in this aspect. It solely depends on your usage to judge whether this new profile is more battery friendly or not. If there are a lot of light-to-medium sustained workloads involved that do not require the user to interact with the phone's screen (e.g. streaming a video on YouTube), then this new profile will work a treat. However, if your usage pattern involves a lot of cases where constant interaction with the screen is essential, then the energy savings will be very slight. Long story short, this profile will increase your battery life, but not always since it hugely depends on your usage pattern in the recorded charge cycle.

So, a new profile that retains the same performance but oozes out a bit more juice from the tank. Sounds very rosy. Well, it isn't all that rosy. There are a couple of corner cases that prove to be heavily impacted with this new profile, which can be classified as high sustained workloads that do not require the user to touch the phone's screen. So far, there seem to be only two cases: end-of-list/end-of-action animation rendering (e.g. the subtle animation rendered when reaching the very end of any particular list after a very quick fling, or the idiotic "time for a stretch" animation that occasionally appears when you call someone and he doesn't pick up after a long time) and CPU-intensive and/or I/O-intensive tasks (such as backing up and restoring apps). While the former is very unlikely to be noticed without sophisticated tools (such as the GPU profiling tool), the latter is very evident. Still, it's not like you will backup and restore your apps every day, but it is worth considering, make no mistake.

So there you have it, turns out that you can squeeze more juice out of this modest 3300mAh juicer, after all. Looking forward to another long-term analysis of another profile. Cheers everyone!