| Age | Commit message (Collapse) | Author |
|---|
|
Need some kind of sanity check to verify work is being done as more
optmizations get done down below
|
|
When a hashed object > 16KiB is encountered, give it to a worker
thread via the newly added iou_async(). The idea here is to not
hold up the serialized iou_run() machinery while grinding on a
large object.
16KiB was pulled out of thin air, I haven't done any profiling to
tune this threshold... just slapped this all together last night.
Will have to get some journals with larger objects for testing,
maybe some coredump.conf::Storage=journal situations, and do some
tuning and timing vs. journalctl --verify.
|
|
This is all forcing clarifying a bunch of details I'm going to
keep putting off and just kicking around to try keep functional
for now.
|
|
Just adding some missing thunk_{mid,end}() return value filters,
which highlights some small optimization opportunities where
these instances aren't being reused.
Still on the fence about this life-cycle approach and naming
though.
|
|
Udpate thunk usage througout to explicitly control thunk instance
lifecycles from calleees according to new model.
This enables discarding a bunch of the per-object dispatch
thunks, eliminates some thunk leaks, and I think generally makes
the code more expressive and clear about what's going on.
Keep in mind this is all experimental and and I'm not spending a
whole lot of time on this, it's mostly a toy and exploring some
different programming styles I'd never really consider for
production/real work.
Though it actually has some interesting properties, and produces
some surprisingly succinct and readable listings at times once
you have the cumbersome building blocks in place. Especially for
non-daemon programs where you can basically either log+ignore
errors or treat them as fatal, I think this programming style
might actually have its place.
|
|
This is currently very hacky and unfinished, but does enough for
some performance comparisons against a zstd-using journalctl --verify
that has been hacked to return early after the first pass.
It's currently rather leaky, the whole per-object-dispatch thingy
is illuminating a thunk_h shortcoming and forcing addressing the
issue... soon.
|
