Startup boost #1696
Startup boost #1696
Conversation
The view of tasks/threads that belong to a process is presented as a flat list in the process' task subdirectory in procfs. There is no need to dig any deeper than that. Fixes: htop-dev#1678 Co-Authored-By: James Abbatiello <abbeyj@gmail.com>
As detailed in commit eb196f8 the UI should receive at least two information gathering cycles before the first data is displayed. Previously, as of the commit mentioned above, there were two expliit call sites that updated the Machine/Process information. These were located as follows: - CommandLine_run (First): Initial scan; used to gather the list of processes as a baseline. Also established a baseline for many of the available meters. - CommandLine_run (Second, removed in this commit): Follow-up scan to refresh information. This scan is the first to use a proper monotonic clock reference. - ScreenManager_run -> checkRecalculation (Third): Run for every refresh cycle at runtime. First scan that allows for proper rate information to be calculated. With the change in this commit the second of these calls is removed, causing the first set of values displayed to lack proper rate information. Fixes: htop-dev#1678 Co-Authored-By: James Abbatiello <abbeyj@gmail.com>
| @@ -398,8 +398,6 @@ int CommandLine_run(int argc, char** argv) { | |||
| Machine_scan(host); | |||
| Machine_scanTables(host); | |||
| CommandLine_delay(host, 75); | |||
| Machine_scan(host); | |||
| Machine_scanTables(host); | |||
|
|
|||
There was a problem hiding this comment.
Pretty sure you can drop the delay on line 400 if we go down this path...? I've always wondered why this second scan/scanTable was there in the original code - perhaps to guarantee values are fully setup (two samples mean all counters are rate converted and ready to display when the UI is presented). But, I'm all for this change if it works.
There was a problem hiding this comment.
In order to avoid a DivByZero for the rate conversion a short delay should be still included. I'll take a look in more detail, if we also can drop line 400.
There was a problem hiding this comment.
If really needed, could the delay perhaps be reduced from 75 to 1 (ms)?
There was a problem hiding this comment.
A reduction should be fine.
The function is called only once and all effects like calling Platform_gettime_realtime(&host->realtime, &host->realtimeMs); are also handled later on, e.g. by checkRecalculation in the ScreenManager code.
Improve startup performance by optimizing how the process list is gathered and how often.
This PR is based on the suggestions from #1678 by @abbeyj.
While this PR is tagged for Linux, it also affects all other platforms due to the second commit. The first commit (improving the process list scanning) only affects Linux, but should be noticeable throughout htop's lifetime.
I'm open for further patches related to performance optimization, in particular ones that affect/improve the startup time.