Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: the tip of my filterx performance efforts #434

Open
wants to merge 56 commits into
base: main
Choose a base branch
from

Conversation

bazsi
Copy link
Member

@bazsi bazsi commented Dec 30, 2024

Please ignore this PR as it is not intended to be merged. It contains work-in-progress local patches I am yet to extract into separate pull requests.

It is rebased on top of my local merge of all related PRs, so I can maintain those branches separately as they get merged.

@bazsi bazsi force-pushed the filterx-perf-project branch 4 times, most recently from 6e3ce03 to 0b045c1 Compare January 5, 2025 16:32
@bazsi bazsi force-pushed the filterx-perf-project branch 3 times, most recently from fbff61c to 5cab36c Compare January 6, 2025 19:10
@bazsi bazsi force-pushed the filterx-perf-project branch 6 times, most recently from d940c50 to 89e67ad Compare January 11, 2025 16:44
bazsi added 15 commits January 17, 2025 10:17
To make it easier to understand stackdumps.

Signed-off-by: Balazs Scheidler <[email protected]>
These were originally optional methods, but that means that descendant
classes will not call the one from LogPipe. Let's create that so
we have a spot to initialize perf trampolines.

Signed-off-by: Balazs Scheidler <[email protected]>
When extracting the source text, we need to split the input into lines.
Previously this was done every time we extracted a line of text, causing
the startup to be very slow when I enabled source extraction for
every FilterXExpr instance.

This patch causes the result of that g_strsplit() call to be saved,
effectively using more memory startup, but being a lot more efficient (e.g.
startup within a second instead of 20 seconds or so).


Signed-off-by: Balazs Scheidler <[email protected]>
In case an expr is optimized we might be setting the location
of exprs multiple times, prepare for this case by freeing expr_text
before setting it first.

Signed-off-by: Balazs Scheidler <[email protected]>
…in addition to is_floating

Signed-off-by: Balazs Scheidler <[email protected]>
…instances

We do not really support message contexts (as does the original filter
language and templates), so remove that support.

This makes it simpler to initialize FilterXEvalContext as well as we do
not have to manage the LogMessage array separately.

Signed-off-by: Balazs Scheidler <[email protected]>
It does not really free @self, so it only clears up allocations
within an existing instance, these are usually called *_clear() functions.

Signed-off-by: Balazs Scheidler <[email protected]>
bazsi added 29 commits January 17, 2025 22:49
Previously a coupling was established between logmsg and FilterXScope,
namely whenever the LogMessage was cloned, the logmsg layer called
filterx_scope_set_log_msg_has_changes(), which was then subsequently
used for invalidating message tied variables in the scope.

This was broken for cases where the message was writable, so it changed
without being cloned. In those cases the stale variables survived anyway.

Another issue was that this produced excessive calls to the expensive
filterx_scope_invalidate_log_msg_cache(), as it may be filterx_scope_sync()
that causes the LogMessage to be cloned. In those cases we executed both
filterx_scope_sync() and an entirely unnecessary
filterx_scope_invalidate_log_msg_cache() both iterating on all
FilterXVariable instances in the scope.

This mechanism is being replaced by the generation counter mechanism, but
to make the patches easier to review, this patch just removes the entire
log_msg_has_changes() mechanism.

Signed-off-by: Balazs Scheidler <[email protected]>
…ocessed

I want to delegate the responsibility of tracking LogMessage changes
to the scope (just as floating values are tracked by it), and as
a preparation add a "msg" member to FilterXScope and make sure
it always contains the right message.

Signed-off-by: Balazs Scheidler <[email protected]>
…XScope

Previously message-tied variables were managed in part within expr-variable
and in part within FilterXScope. Now with the message being available
in FilterXScope, we can delegate this in entirety to FilterXScope.

This also implements the validation of message-tied values, so if the
LogMessage changes independently from FilterXScope, we will notice that too
and consider the values of those variables stale.

Signed-off-by: Balazs Scheidler <[email protected]>
A scope is only considered dirty if it has message-tied variables that
are changed. In any other case it's not dirty, so no sync is needed.

Signed-off-by: Balazs Scheidler <[email protected]>
Link scopes together.

Signed-off-by: Balazs Scheidler <[email protected]>
…rations

Previously generations was reset to 0 in case we ended up doing a clone.
Let's retain that instead, so we don't need to adjust the generation
value for FilterXValues either. This is a preparation for sharing
FilterXVariable descriptors so that we don't have to clone them.

Signed-off-by: Balazs Scheidler <[email protected]>
Instead of cloning all variables into subsequent scopes, let's start with an
empty array and only clone the ones that are actually used.  This improves
performance a lot in our use-cases.

Signed-off-by: Balazs Scheidler <[email protected]>
…he stack

At the same time get rid of reference counting and clone.

Signed-off-by: Balazs Scheidler <[email protected]>
Although this code has a single user, it is relatively complex, relies
on arcane mechanics of FilterXScope and FilterXEvalContext. Hide it
and delegate it to show where it belongs.

These have become macros, as we need to use the caller's stack frame to
allocate the scope.


Signed-off-by: Balazs Scheidler <[email protected]>
Sometimes location tracking is buggy, make sure we don't address outside
of the source text.

Signed-off-by: Balazs Scheidler <[email protected]>
This reverts commit 350c1cab2e643d12c280c7df0e402e96694f72e2.
This is probably the next most accessed field in that struct.

Signed-off-by: Balazs Scheidler <[email protected]>
Signed-off-by: Balazs Scheidler <[email protected]>
…BJECT_REFCOUNT_FROZEN

Signed-off-by: Balazs Scheidler <[email protected]>
Instances of strings that are only used once for a brief period
can be allocated on the stack to reduce malloc() calls. This is especially
useful when iterating over a lot of FilterXString instances, most of
which is imediately dropped away.

Signed-off-by: Balazs Scheidler <[email protected]>
@bazsi bazsi force-pushed the filterx-perf-project branch from b5e373f to 1cad834 Compare January 17, 2025 22:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant