-
Notifications
You must be signed in to change notification settings - Fork 443
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
Reduce mem allocations #729
Conversation
Fix typo in comment
Avoid recreating strings within n_plus_one_query
lib/bullet/ext/string.rb
Outdated
def bullet_class_name | ||
sub(/:[^:]*?$/, '') | ||
@bullet_class_name ||= begin | ||
last_colon = self.rindex(':') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
microbenchmark on sub showed rindex is about twice as fast for this sort of work.
memoizing here is just the cherry on top
Its causing all the specs to fail, however I was not able to figure out why it was doing so...
I don't believe primary_key is ever changed within a request
3f8ff37
to
f9677ab
Compare
I haven't changed anything relevant to the CI and each failed job seems to relate to a CI change rather than the code changes here... Not sure what's up with that. |
@vprigent great job on performance tuning, thank you, I'll merge it and fix the CI. |
As mentioned below, I'm unsure as to what is making the tests fail.
Benchmark:
Using a local projects page firing 42 queries and detecting one
include
missing:On 8.0.0
Patch:
Running the benchmark:
8.0.0
Patch:
Which is a surprising improvement, considering I was mostly aiming at reducing the memory usage. I suspect this will actually be more valuable than the 5% memory usage reduction for most people.
Happy for you to review the changes @flyerhzm
I'm not sure how to solve the specs all failing at this time.
I believe there's still a fair bit on the table within the naive implementation for grabbing stack traces, we could for a start limit the size of the stack trace we grab by using
caller(0..n)
overThread.current.backtrace
or filter straight as we grab the content of the backtrace might do the trick too?