diff options
author | 2024-02-24 14:42:43 +0100 | |
---|---|---|
committer | 2024-02-24 20:08:27 -0800 | |
commit | 2be5051b19a397eff187b2f458b0c8aeece4e83b (patch) | |
tree | 021f27f5a8280a6902051223623d73c57da1e04f /internal/template/functions.go | |
parent | c544dadd55b3f96d0f488d0c3e4266ae9f15d71f (diff) | |
download | v2-2be5051b19a397eff187b2f458b0c8aeece4e83b.tar.gz v2-2be5051b19a397eff187b2f458b0c8aeece4e83b.tar.zst v2-2be5051b19a397eff187b2f458b0c8aeece4e83b.zip |
Reorder the fields of the Entry struct to save some memory
Given that there is always a ton of `Entry` floating around, reordering its
field to take less space is a quick/simple way to reduce miniflux' memory
consumption.
I kept the `ID` field as the first member, as I think it's the most important
one, and moving it somewhere else would drown it in other fields.
Anyway, this still provides a reduction of 32 bytes per Entry:
```console
$ fieldalignment ./client/model.go 2>&1 | grep 203
~/v2/client/model.go:203:12: struct with 280 pointer bytes could be 240
$ fieldalignment ./client/model.go 2>&1 | grep 203
~/v2/client/model.go:203:12: struct with 248 pointer bytes could be 240
$
```
The same optimisation pass could be applied to other structs, but since they
aren't present in obviously great numbers during miniflux' life cycle, it would
likely require some profiling to see if it's worth doing it.
Diffstat (limited to 'internal/template/functions.go')
0 files changed, 0 insertions, 0 deletions