Add PerformanceSensitive annotations #2037
Conversation
Document module, class, and/or method performance characteristics.
Generate changelog in
|
tritium-annotations/src/main/java/com/palantir/tritium/annotations/PerformanceSensitive.java
Outdated
Show resolved
Hide resolved
| * when modifying this element. | ||
| */ | ||
| @Target({ElementType.TYPE, ElementType.METHOD, ElementType.MODULE}) | ||
| @Retention(RetentionPolicy.RUNTIME) |
There was a problem hiding this comment.
Do we need runtime retention? If we're using this as a target to opt into specific static analysis rules, SOURCE retention should be sufficient (and doesn't require us to include jars at runtime)
There was a problem hiding this comment.
I was thinking we could do bytecode inspection, but probably not necessary now.
There was a problem hiding this comment.
We could still write error-prone checks validating certain behaviors (e.g. restricting use of streams within certain scopes).
There was a problem hiding this comment.
Source retention should be fine for this case, as long as we’re inspecting the annotated element. I imagine calling into a perf sensitive method shouldn’t be relevant to the caller, so bytecode retention shouldn’t buy us much unless we want to add specific instrumentation 👍
| /** | ||
| * This element is sensitive to object allocations. | ||
| */ | ||
| Allocations, |
There was a problem hiding this comment.
Pedantic naming nits:
Perhaps allocation should be singular matching cache? As in “allocation sensitive”.
We usually use all-caps enum constants, might be worth standardizing
|
Lgtm, defer to your judgement on the naming comment 👍 |
|
👍 |
|
Released 0.94.0 |
Before this PR
Tritium had no mechanisms for documenting the performance characteristics and considerations for modules, classes, or methods.
After this PR
==COMMIT_MSG==
Document module, class, and/or method performance considerations.
==COMMIT_MSG==
Possible downsides?