Dropped lfs3_file_weight_

Now that ungrafted leaves are much more limited in scope, I'm not sure
lfs3_file_weight_ still makes sense as a separate function.

The only call was in lfs3_file_read, where we decide if we bother
flushing things before actually flushing things. Given that we should
now generally graft before expecting lfs3_file_lookupnext to make sense,
relying on lfs3_file_weight_ too much probably hints at a logic mistake.

This logic ends up inlined anyways, so no code changes:

           code          stack          ctx
  before: 36992           2352          684
  after:  36992 (+0.0%)   2352 (+0.0%)  684 (+0.0%)
This commit is contained in:
Christopher Haster
2025-08-04 15:57:32 -05:00
parent 15c3d2f87a
commit be3e61dd13

22
lfs3.c
View File

@ -12499,20 +12499,18 @@ static inline lfs3_size_t lfs3_file_cachesize(lfs3_t *lfs3,
: lfs3->cfg->file_cache_size;
}
static inline lfs3_off_t lfs3_file_weight_(const lfs3_file_t *file) {
static inline lfs3_off_t lfs3_file_size_(const lfs3_file_t *file) {
#ifndef LFS3_KVONLY
return lfs3_max(
file->leaf.pos + file->leaf.weight,
file->b.shrub.r.weight);
file->cache.pos + file->cache.size,
lfs3_max(
file->leaf.pos + file->leaf.weight,
file->b.shrub.r.weight));
#else
return file->b.shrub.r.weight;
#endif
}
static inline lfs3_off_t lfs3_file_size_(const lfs3_file_t *file) {
return lfs3_max(
LFS3_IFDEF_KVONLY(0, file->cache.pos) + file->cache.size,
lfs3_file_weight_(file));
file->cache.size,
file->b.shrub.r.weight);
#endif
}
@ -13087,7 +13085,9 @@ lfs3_ssize_t lfs3_file_read(lfs3_t *lfs3, lfs3_file_t *file,
}
// any data in our btree?
if (pos_ < lfs3_file_weight_(file)) {
if (pos_ < lfs3_max(
file->leaf.pos + file->leaf.weight,
file->b.shrub.r.weight)) {
if (!lfs3_o_isuncryst(file->b.h.flags)
&& !lfs3_o_isungraft(file->b.h.flags)) {
// bypass cache?