From 3de90b93ecf89eb5c8d6c9292a355086cb79f61e Mon Sep 17 00:00:00 2001 From: Nicolas Boichat Date: Sun, 20 Apr 2025 15:18:52 +0200 Subject: [PATCH] ls/BENCHMARKING.md: Add some tricks --- src/uu/ls/BENCHMARKING.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/uu/ls/BENCHMARKING.md b/src/uu/ls/BENCHMARKING.md index 3103e43b0..3611d7a96 100644 --- a/src/uu/ls/BENCHMARKING.md +++ b/src/uu/ls/BENCHMARKING.md @@ -1,6 +1,13 @@ # Benchmarking ls ls majorly involves fetching a lot of details (depending upon what details are requested, eg. time/date, inode details, etc) for each path using system calls. Ideally, any system call should be done only once for each of the paths - not adhering to this principle leads to a lot of system call overhead multiplying and bubbling up, especially for recursive ls, therefore it is important to always benchmark multiple scenarios. + +ls _also_ prints a lot of information, so optimizing formatting operations is also critical: + - Try to avoid using `format` unless required. + - Try to avoid repeated string copies unless necessary. + - If a temporary buffer is required, try to allocate a reasonable capacity to start with to avoid repeated reallocations. + - Some values might be expensive to compute (e.g. current line width), but are only required in some cases. Consider delaying computations, e.g. by wrapping the evaluation in a LazyCell. + This is an overview over what was benchmarked, and if you make changes to `ls`, you are encouraged to check how performance was affected for the workloads listed below. Feel free to add other workloads to the list that we should improve / make sure not to regress.