{"id":4058,"date":"2017-06-21T16:06:06","date_gmt":"2017-06-21T21:06:06","guid":{"rendered":"http:\/\/neosmart.net\/blog\/?p=4058"},"modified":"2018-01-13T14:54:23","modified_gmt":"2018-01-13T20:54:23","slug":"prettysize-a-net-library-for-printing-human-readable-file-sizes","status":"publish","type":"post","link":"https:\/\/neosmart.net\/blog\/prettysize-a-net-library-for-printing-human-readable-file-sizes\/","title":{"rendered":"PrettySize: a .NET library for printing human-readable file sizes"},"content":{"rendered":"

\"\"<\/a>Continuing our promise to open source parts of our libraries and applications where possible, we’ve just released PrettySize<\/code>, a C# and .NET library for representing file sizes in a human-readable (pretty) format. PrettySize<\/code>\u00a0is available for free (MIT-licensed) on GitHub<\/a> and via NuGet<\/a>\u00a0for those that are interested, and forks, contributions, and pull-requests are actively encouraged.1<\/a><\/sup><\/p>\n

One of the best benefits of open-sourcing code is that it requires you to take a critical eye to what your code does and how it’s structured. Haphazard code interspersed throughout a dozen different files is cleaned up and re-organized in a way that can only bring benefits all around, from performance to ease-of-use, security, and future maintenance.<\/p>\n

<\/p>\n

In this example, PrettySize<\/code>\u00a0went from supporting just a single notation format (2.34 KiB<\/code>, for example), to supporting output using both base 10 (kilobyte, megabyte, KB, MB) and base 2 (kibibyte, mebibyte, KiB, MiB) units, with support for both abbreviated and unabridged units in the output.<\/p>\n

Additionally, open-sourcing PrettySize<\/code>\u00a0also brought some performance improvements to bear (although any honest appraisal of the situation would start and end with pointing out that any sort of human-readable formatting is almost always going to be part of a much slower path in the code, namely printing to screen or similar, to an extent that actually forming the human-readable strings in question is going to be of negligible overhead), as the code went from a sequence of if (...) else ...<\/code>\u00a0statements like this:<\/p>\n

if (size < 1 * (1L << 10))\r\n{\r\n    return size + \" bytes\";\r\n}\r\nelse if (size < 10 * (1L << 10))\r\n{\r\n    return (size \/ (1.0 * (1L << 10))).ToString(\"N2\") + \" KiB\";\r\n}\r\nelse if (size < 100 * (1L << 10))\r\n{\r\n    return (size \/ (1.0 * (1L << 10))).ToString(\"N1\") + \" KiB\";\r\n}\r\n...\r\n<\/code><\/pre>\n
where conversions of larger file sizes would have to go through each successive test until the matching clause was found, to a binary search performed against a sorted array of match ranges.<\/p>\n
While the .NET Framework has included a binary tree-based SortedDictionary<\/code>\u00a0since .NET 2.0, it unfortunately does not support “fuzzy” lookups (\u00e0 la C++’s std::map<\/code>) where the nearest match can be returned, and so manipulations would be required to incoming sizes before being able to match them against a pre-existing lookup table. On the other hand, Array.BinarySearch<\/code>\u00a0will return the (binary, two’s complement) of the closest (higher) match if no exact match was found, letting us create a sorted list of formatting rules for each range, and then find the nearest match to service incoming requests.<\/p>\n
In addition to converting numeric file sizes to formatted strings for human-readable representation, PrettySize<\/code>\u00a0also includes constants that can be used to make expressing your own size-related calculations easier, with both base 2 and base 10 units (and their abbreviations) exposed.<\/p>\n
Some random facts learned in the process:<\/p>\n