How come readFileAlloc is not using .fill() trick underneath if that is most efficient? I took a look at implementation (0.15.2) and it creates array list and reads into it. Array list should be created with enough capacity so performance should be the same?
Regarding the File Lines article I was expecting reading the file line by line and allocating only as much is needed for line to save memory if you have a very large file.
Well first, It’s using the old reader API, which does not, and cannot have a fill function as buffering is not built into that old API.
Second, fill is not more efficient, all it does is read into the interface buffer in a loop until the requested amount of bytes has been read.
They are doing basically the same thing, with the caveat that the array list may grow, which does make it less efficient, but by default it is pre-allocated with the size of the file so that’s not an issue unless you provide the size_hint parameter.
Lastly, I pointed earlier in this thread that: giving the reader the buffer and calling fill(buf.len), is identical to providing no/a different buffer to the reader and calling readSliceAll(buf).
The person(s) saying there is unnecessary buffer copying, and that fill is most efficient, are just incorrect.
There is not some magical function that reads into a buffer faster than any others.
This one reads the lines one by one, only allocating as much memory as needed for one line and reusing the same line buffer for all the lines. Back to Basics: File Reading with the New IO in Zig | Software Fragments