Benchmarking some lld revisions

[George Rimar via llvm-commits]

>Having a human readable percentage would be useful when backreferencing from the visualization to the revision number.


Yeah, that was my case. At first I looked at plot but then was interested in numbers.


>In general though, unless you are looking for a very specific thing (like the exact revision number of a commit you found from a >visualization), scanning lists of numbers for outliers (or any insight whatsoever) is extremely unreliable. It is also very time >consuming because you are never sure that you "caught everything" and so will keep scanning the data looking for things you >missed (and will still miss things).
>At the very least, if you need to scan a list of numbers like percentage increase/decrease, I would highly recommend importing >it into a spreadsheet and applying conditional formatting to color large values. Then it can be scanned relatively quickly and >reliably. Even better, just sort based on the percentage increase/decrease.
>
>For this reason, I would always recommend printing raw data in the least human-readable format possible (while still being >machine readable), e.g. for printf I would recommend something horrible like `%.18e` to mitigate the temptation to look at the >raw data without some sort of analysis or visualization.

:) I see. Thanks for explanation.

>
>With a good visualization (in this case, a simple scatter plot; for extra credit, adding error bars like Rafael did), you can instantly >see that there are 3 major revisions to look at and no larger-scale "death by 1000 cuts" progressive slowdown.
>
>-- Sean Silva

George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170601/4ec8a5bf/attachment.html>