Sort history graph columns by graph area

[ion1]

Is your feature request related to a problem? Please describe.

When sorting the process list by a history graph column, it would feel intuitive to me if the list was sorted by the area of each visible graph. I think it is currently sorted by the current value, making sorting by that column redundant since there is already a sortable column for that.

Describe the solution you'd like

I would like the graph columns to be sorted by the area of the currently visible graph.

Describe alternatives you've considered

The alternative is to keep the status quo, I suppose.

Additional context

An example where I would expect the fifth item to be within the top three because its area exceeds that of the two or three items above it:

[dmex]

it is currently sorted by the current value

This was done for performance reasons since the history buffer for each graph is determined by the width of the monitor.

For example; Every graph on a 1920x1080 screen contains 1080 values (8 bytes per value) multiply this by the number of current processes (300?) and you have 324,000 values total.

Sorting can only ever be done using a single value, so this means having to create an average or summing the numbers into a single value. Since the processes list/graphs are real-time, sorting is always updated before every interval update (generally once per second,so to sort the columns by the graph area PH would have to loop each graph and each value 324,000 times a second.

The time required to preform those loops and average/sum the values 'eats' away the CPU time for other updates/operations that had to be updated within each interval update... so the sorting for the history graph columns currently just uses the most recent, last value from the graph without going through all those loops.

I would like the graph columns to be sorted by the area of the currently visible graph.

The only problem is how to sort the graph values. It would have to average all the values or total all the values but this won't match what you're seeing in the graphs?

[Ishmaeel]

I have been keeping an eye on this issue. I even briefly tried my hand in it but did not make much progress due to being a total C/C++ noob. Anyway, sorting by current value is entirely useless and misleading, IMHO.

Sorting would be done best over the grand total, as it would give the most accurate approximation to the "area" of the graph (=the total CPU burned by the process in the recent past).

How about calculating the totals during the draw phase and caching the value for the next cycle? The code is going through all the values while drawing anyway.

[ion1]

For example; Every graph on a 1920x1080 screen contains 1080 values (8 bytes per value) multiply this by the number of current processes (300?) and you have 324,000 values total.

You can keep a single sum value per graph. When you append a data point, add its value to the sum. When you remove an old data point, subtract it from the sum.

I suppose the actual implementation is a circular buffer. When a data point is being replaced, subtract the old one first and add the new one.