4 ms·

- it will produce OOM if file is very large A well designed API won't give you an OOM it'll throw a 'this file is too big' - not sure why you would want to

- it will produce OOM if file is very large A well designed API won't give you an OOM it'll throw a 'this file is too big' - not sure why you would want to have path and filename as separate params Throws path not found. Throws file not found. Why does the programmer need to deal with twee-fiddly path magic for say each file in a directory of config files? Iterable<String> Files.readAllLines(String fileName); Oh sure that's totally more readable. I think in python it will lazely iterate through the file, I wrote a program to suck in a list of log files and generate a bunch of metrics and display them. Users liked to select a dozen 100MB log files. Lazy iteration was way way too slow. Fastest was suck each one into memory and call split.

riku_iki 3y ago
> A well designed API won't give you an OOM it'll throw a 'this file is too big' this is possible solution, still it doesn't allow to iterate lines one by one and handle large files > Throws path not found. Throws file not found. I think it is some very niche use cases when you need to distinguish between these cases. From another hand there are many places in the code which operate absolute file paths already, and you force them to split path, which is cumbersome. At least two alternative APIs probably are justified to have. > Fastest was suck each one into memory and call split. I really don't think pre-splitting is any kind of performance bottleneck, it is likely 1% of performance compared to all IO stack and subsequent string/objects memory management.