Overhauling Human-Readable Sizes #224
Comments
|
Are you keeping the two-shaded coloring for values in different scales? I.e. for |
|
It does not use two-shaded coloring. The color represents the largest whole binary suffix that applies, which is mildly independent of the actual number that is displayed.
In this way, the user can see things at a glance:
The benefits are that the numbers are much more human-readable, and the colors indicate a bit of the missing precision. |
|
I don't think the user will get the difference between 1024 being displayed in MB_COLOR or GB_COLOR without it being explained. While the (existing) two-color display doesn't need much explanation it also has the visual bonus of making the numbers easier to parse at a glance. When I recently changed the display of the size values I extended this visual clue from the KB/MB precision to MB/GB because having this clue makes parsing out the GB part much easier. |
|
Here is a comparison of the text between the 2 display formats we are currently comparing:
Here is the coloring:
I'm not even sure what the existing two-color system is trying to say there. Here is another example:
It's clear that the existing two-color display is using a mishmash of base 10 and base 1024 units, which is fairly unintelligible if not incorrect. The existing code also fails at larger numbers, becoming too wide for the field:
I would suggest the format I've presented should be the default, intended for casual users. Maybe there could be other schemes for more advanced users.
|
|
Looking through the issue tracker I found another issue regarding the display format, that could become a good middle ground between the new scheme and the two-color system. Have a look at the format suggested in #35 (examples in hishamhm/htop#901). The numbers could be used as shown in your demonstration (no objections on removing the base 10/2 mix). Coloring could then become 13G37 for 13.37 GiB, marking the 13G part as gigabytes, and the fraction part (37) as megabytes. That's also basically what the intent of the current scheme ist. Reason: Avoiding large numbers with many equally colored digits to provide some visual clues for fast parsing. FWIW: The letter for the unit should be kept for UI reasons (e.g. on monochrome displays) and for visually impaired users. Conveying information purely through color is a bad accessibility option. |
|
That sounds good. I'll change the code I'm working on to use that notation. |
|
I am not quite sure what this addresses. I am fine with changing the columns in process list. |
|
The change affects the display of the various columns like virtual size. For Meters a different function is used. Thus no changes there. |
|
Yes, I know a different function is used for meters... It was me who implemented the human readable sizes there. ;) So all for this! |
|
Hi. May I make some comments on this? I'm really not sure if displaying "97.7M" and "99.9M" in the above example is a good idea. For me it looks like an over-precision and increased confusion, since many people are not yet aware of the base-1000 and base-1024 differences. Of course the memory usage scale should be base-1024, but I have three suggestions here:
|
|
I think rounding-wise we should care at most about the two most significant units. Thus For this matter After this normal rounding rules should be applied for display. For values in front of the decimal point above 1000 the next bigger unit should be used, utilizing binary prefixes for conversion. Exception should be |
|
@BenBE Just for the info, the reason I vote for rounding upward (and never truncate) is that I don't wish to give users a false estimate on how much memory is needed for an application. For example, the display of "4.00G" should mean the app uses close to but not more than 4 GiB (there would always be memory bytes unused due to allocation/paging/alignment overheads). I think memory usage numbers also round up in Windows Task Manager. Just for reference. |
|
I made a correction on the suggested example in my previous comment. |
|
@Explorer09 has raised these points:
Here are my thoughts on these points:
|
Where comes the GongS from? Couldn't find a source for that name? Closest I found was RKM from IEC 62 …
Just remove one finger from each hand and hexadecimal becomes surprisingly practical … |
|
|
|
|
@BenBE |
|
When to use fractions depends on the precision. With three figures after the decimal point, the smallest step (0.001) in the fractional notation is slightly larger than the smallest step (1) in the next lower unit: Therefore, you get the best precision by avoiding the switch to a higher unit; you should count as long as possible in the lowest possible unit; every coefficient should be maxed out to 9999 before switching to fractional notation. You could get more precision by replacing both the decimal point and the leading zero with the unit: Then it becomes a little less intuitive about when it makes sense to transition to the next higher unit, in general; however, the result actually satisfies @Explorer09's desire not to display a value >= 1000:
|
|
I don't like skipping the leading 0. Thus I much prefer |
|
What just...happened? |
ghost
mentioned this issue
|
@pthfdr-42 That's basically what we're discussing, as the k/M/G/… prefixes are usually used as KiB/MiB/GiB/… (i.e. scaling 1024) when dealing with amounts of memory, thus using 1000 for scaling is at least unexpected (and doesn't even align with what the current implementation* does). What the current discussion is mostly still working out are 1) the best (and most consistent) points to do the transition from one unit to the next bigger one and 2) whether to skip leading zero or not. Apart from those open questions I think we already got a rough consensus on where it should go. *That's on a completely different page. Don't look for any consistency there. |
|
You shouldn't ever have |
|
@BenBE Well, if the 1000-vs-1024 thing is important, then just give an option in display settings. |
|
I for one don't want to see the base shown in the results at all as it just breaks comprehension completely and overloads you with unnecessary information. Either let's have an option to switch between bases or just stick to 1024. I prefer the latter because RAM has been historically in 2^10 units. @mfwitten Please please add an option to hide zeros from the output. |
|
@birdie-github State of discussion currently is for using 1024 exclusively. The old code wasn't consistent in this regard, thus there will be some minor tweaks to fix these. |
|
@birdie-github I personally prefer adding an option to toggle 1000/1024, with 1024 being the default. This clarifies lots of things (I do not know whether it is 1000 or 1024). |
|
The general rule for volatile memory (RAM, cache) is to use IEC binary prefix while persistent storage (disks, SSDs, etc), always use SI decimal prefixes. So 1 GB is always 1 000 000 000 GB and nothing else. The BIPM forbids the abuse of SI prefixes for binary use. |
BenBE
added
the
needs-discussion 🤔
Yeah, maybe, but eg Kubernetes supports both for specifying RAM limits. (It's my current use case for keeping a careful eye on RAM usage.) I used to be a defender of the power-of-2 prefixes, but I've come to realize that they were useful when RAM was tiny and data structures (which were often size with powers-of-2 for slightly easier addressing) were few in number. Now that we're administering machines with gigabytes of RAM and even programmers rarely allocate power-of-2 data structures, binary prefixes only offer pain instead of convenience. |
|
Also please display the K prefix. It's confusing that htop omits it. And |
Allocating in power 2 is advisable if you need proper alignment of data in memory. |
No, not exactly. In any case, if you're an embedded or low-level programmer who cares about these things, then you take out your calculator. It's time for users to stop having to put up with it. |
I've got some code in the works to improve
Process_humanNumber():unsigned long longis used only as necessary.I intend to clean up the code in the coming days, and then I will submit a PR. In the mean time, here is the output from a test program; let me know what you think:
The text was updated successfully, but these errors were encountered: