On Mon, Feb 19, 2024 at 07:53:15PM +0000, David Laight wrote: > ... > > I'm not always trying to write code that will generate the fastest > > assembly possible; there aro other considerations. As long a the > > compiler is doing something /reasonable/, the code is fine. > > Speaks the man who was writing horrid 'jit' code ... > > This also begs the question of why that data is so compressed > in the first place? > It is quite likely that a few accesses generate far more code > than the data you are attempting to save.
It's easy to understand if you understand profiling, benchmarking and cache effects. That 'jit code' is for _all_ filesystem metadata.
