we know we won't need them.
Knowing whether we need them is accomplished by pulling the "show-costs"
option used by the Close command up into ReportOpts.
existing representation is small enough.
Previously the JSON representation of Decimal was rounded to 10 points
of precision before serialising. This sometimes results in an
unnecessary increase of precision.
Prior to this commit,
- hledger still builds with GHC 8.0
- hledger-ui does if you use the build plan specified by stack8.0.yaml,
but you are likely to hit problems if you let cabal pick one
(https://github.com/jtdaugherty/vty/issues/198 and others)
- hledger-web might, if you could find the right build plan
The hassles are enough and GHC 8.0 is old enough (first released in
2016) that I'm letting it go; 8.2 is the new minimum version for all
hledger packages.
This allows a bunch of cleanups to conditional imports, which I leave
for later.
Also, updated the tested-with minor versions.
It was reported on #hledger that bal -O csv capitalises "account"
differently for single and multi-period reports. All lower case seems
to be the most common, so I have dropped the capitalisation. Also
the trailing colon from --transpose's "total:".
It now uses the same JSON representation as Maybe Word8. This means that
the JSON serialisation is now broadly compatible with that used before the
commit f6fa76bba7, differing only in
how it handles numbers outside Word8 and that it can now produce null
for NaturalPrecision.
Comparing two Quantity (either with (==) or compare) does a lot of
normalisation (calling roundMax) which is unnecessary if we're comparing
to zero. Do things more directly to save work.
For reg -f examples/10000x10000x10.journal, this results in
- A 12% reduction in heap allocations, from 70GB to 62GB
- A 14% reduction in (profiled) time, from 79s to 70s
Results for bal -f examples/10000x10000x10.journal are of the same order
of magnitude.
rather than lists. This is probably not an enormous performance sink in real
situations, but it takes a huge amount of time and memory in our
benchmarks (specifically 10000x10000x10.journal).
For bal -f examples/10000x10000x10.journal, this results in
- A 23% reduction in heap allocation, from 27GiB to 21GiB
- A 33% reduction in (profiled) time running, from 26.5s to 17.9s
Strip prices after valuing postings in PostingsReport.
Use renderRow interface for Register report.
For reg -f examples/10000x10000x10.journal, this results in:
- Heap allocations decreasing by 55%, from 68.6GB to 31.2GB
- Resident memory decreasing by 75%, from 254GB to 65GB
- Total (profiled) time decreasing by 55%, from 37s to 20s
former being a simple wrapper around the latter.
This removes the need for the showNormalised option, as showMixedAmountB
will always showNormalised and showAmountsB will never do so.
We also strip prices from MixedAmount before displaying if not displaying prices.
