forked from Imagelibrary/littlefs
Reverted limiting file->leaf to reads + erased-state caching
Still on the fence about this, but in hindsight the code/stack
difference is not _that_ much:
code stack ctx
before: 36460 2280 636
after: 37092 (+1.7%) 2304 (+1.1%) 636 (+0.0%)
Especially with the potential to significantly speed up linear file
writes/rewrites, which are usually the most common file operation. You
ever just, you know, write a whole file at once?
Note we can still add the previous behavior as an opt-in write strategy
to save code/stack when preferred over linear write/rewrite speed.
This is actually the main reason I think we should prefer
lazy-crystallization by default. Of the theoretical/future write
strategies, lazy-crystallization was the only one trading performance
for code/stack and not vice versa (global-alignment, linear-only,
fully-fragmented, etc).
If we default to a small, but less performant filesystem, it risks users
thinking littlefs is slow when they just haven't turned on the right
flags.
That being said there's a balance here. Users will probably judge
littlefs based on its default code size for the same reason.
---
Note this includes the generalized lfsr_file_crystallize_ API, which
adds a bit of code:
code stack ctx
before gen-cryst: 37084 2304 636
after gen-cryst: 37092 (+0.0%) 2304 (+0.0%) 636 (+0.0%)
This commit is contained in:
@@ -44,6 +44,8 @@ FLAGS = [
|
||||
('^', 'ORPHAN', 0x50000000, "Type = orphan" ),
|
||||
('^', 'TRAVERSAL', 0x60000000, "Type = traversal" ),
|
||||
('^', 'UNKNOWN', 0x70000000, "Type = unknown" ),
|
||||
('o', 'UNCRYST', 0x00400000, "File's leaf not fully crystallized" ),
|
||||
('o', 'UNGRAFT', 0x00800000, "File's leaf does not match bshrub/btree" ),
|
||||
('o', 'UNFLUSH', 0x01000000, "File's data does not match disk" ),
|
||||
('o', 'UNSYNC', 0x02000000, "File's metadata does not match disk" ),
|
||||
('o', 'UNCREAT', 0x04000000, "File does not exist yet" ),
|
||||
|
||||
Reference in New Issue
Block a user