-S, --buffer-size=SIZE
use SIZE for main memory buffer
[...]
SIZE may be followed by the following multiplicative suffixes: % 1% of memory, b 1, K 1024 (default), and so on for M, G, T, P, E, Z, Y.
(this could be a good first issue)
The text was updated successfully, but these errors were encountered:
There is an even bigger problem here, which is that sort precomputes data for each line that will be sorted (this makes comparing them faster). Due to that the exact amount of memory usage depends on the number of lines in a chunk (shorter lines -> more lines in a chunk -> more memory usage).
Right now, when you specify a buffer size, the actual memory usage will be less or more than that. I think we should first solve that problem.
Addresses issue uutils#3500, which calls for sort to permit percentage values
for the buffer-size flag. Portability is an issue here, but I don't
think this change constrains `sort`'s portability any more than its
dependencies already do.
To calculate a fraction of the system's memory, naturally we need to
retrieve the system's total memory. GNU's equivalent -- see
`physmem_total` in `lib/physmem.c` in gnulib -- has a series of `ifdef`s
to decide how to retrive the value. Each platform has its own
considerations, and the result is a pretty serious mess.
This patch omits that mess. In exchange, it will only work on platforms
with a functioning libc. The thing is, `sort` already includes libc,
which is why I said this patch doesn't introduce new constraints on
`sort`'s portability.
GNU sort v. Rust sort:
Relevant excerpts from GNU sort manpage:
(this could be a good first issue)
The text was updated successfully, but these errors were encountered: