-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
ArC micro optimizations #18567
ArC micro optimizations #18567
Conversation
I also tried to do some inexact and naive tests with the hibernate-orm-quickstart where exactly 50 beans is removed by default:
I tested the
|
@Sanne It would be great if you could run your tests again and confirm/disprove my findings. FYI I cherry-picked 5 of your commits and only left out those that modified the |
return Collections.emptySet(); | ||
return Set.of(); |
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.
I didn't know this was actually better
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.
I had never seen this method :) Seems it's new in Java 9.
But also it's a constant in both cases apparently... I suppose you prefer it because of style Martin ?
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.
It's not better, I just wanted to be consistent here... ;-)
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.
LGTM
return Set.of(set.iterator().next()); | ||
case 2: | ||
Iterator<T> it = set.iterator(); | ||
return Set.of(it.next(), it.next()); |
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.
hum, Set.of( )
produces an object of 24 bytes, while Collections.singleton
16 ,,. previous was better?
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.
So I suppose you mean the java.util.ImmutableCollections.Set12
which is used for both a singleton and a doubleton.
- Previously, we did not use a specialized set for a doubleton, which is a pity because in CDI doubletons are quite common.
- I don't think it's reasonable to sacrifice the consistency for 8 bytes...
this.description = description; | ||
this.types = CollectionHelpers.toImmutableSmallSet(types); | ||
this.qualifiers = qualifiers != null ? CollectionHelpers.toImmutableSmallSet(qualifiers) | ||
: Qualifiers.DEFAULT_QUALIFIERS; | ||
this.qualifiers = CollectionHelpers.toImmutableSmallSet(qualifiers); |
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.
I don't understand this, it looks lik you rather prefer to always allocate a new wrapping collection? I was trying to avoid those when not necessary.
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.
Note really, the qualifiers
set is always null for default qualifiers and CollectionHelpers.toImmutableSmallSet()
returns null
for null
param.
@@ -387,16 +387,26 @@ void addComponentInternal(ObserverInfo observer) { | |||
private final ResultHandle removedBeansHandle; | |||
private final ClassOutput classOutput; | |||
private ResultHandle tccl; | |||
// Shared annotation literals for an individual addRemovedBeansX() method | |||
private final Map<AnnotationInstanceKey, ResultHandle> sharedQualifers; |
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.
Is that worth it?
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.
I think it is. For example, because of SR Config almost every app will have ~ 30 removed beans with the @ConfigProperty
qualifier, which in turn results in a new AnotationLiteral
instance stored in the removedBeans
list. This way, we can reduce the number of annotation literal instances to 2 (for the hibernate-orm-quickstart
).
I think we should merge this. We can still improve later on top of this if needed. |
- trim list of removed Beans - trim Resource reference providers - trim active Beans - do not use LinkedList - share qualifier annotation literals and Type instances in the generated ComponentsProvider Co-authored-by: Sanne Grinovero <sanne@hibernate.org>
26460c5
to
ffa6e30
Compare
This workflow status is outdated as a new workflow run has been triggered. 🚫 This workflow run has been cancelled. Failing Jobs - Building 26460c5
Full information is available in the Build summary check run. Test Failures⚙️ JVM Tests - JDK 11 #📦 extensions/arc/deployment✖ ⚙️ JVM Tests - JDK 11 Windows #📦 extensions/arc/deployment✖ ⚙️ JVM Tests - JDK 16 #📦 extensions/arc/deployment✖ |
The PR is ready now... |
generated ComponentsProvider
Co-authored-by: Sanne Grinovero sanne@hibernate.org