I like this. A lot of the logging code is critical path/performance sensitive.
Allowing a “reason” or reasons helps a lot.
Ralph
> On Feb 21, 2016, at 9:25 PM, Matt Sicker wrote:
>
> Syntax-wise, you can use either @PerformanceSensitive("foo") or
> @PerformanceSensitive({"foo", "bar"})
>
> O
Ah, that would be fine!
On Monday, 22 February 2016, Matt Sicker wrote:
> Syntax-wise, you can use either @PerformanceSensitive("foo") or
> @PerformanceSensitive({"foo", "bar"})
>
> On 21 February 2016 at 22:23, Matt Sicker > wrote:
>
>> I can change it for the former (you need to use a string
Syntax-wise, you can use either @PerformanceSensitive("foo") or
@PerformanceSensitive({"foo", "bar"})
On 21 February 2016 at 22:23, Matt Sicker wrote:
> I can change it for the former (you need to use a string array, though),
> the latter is only possible in Java 1.8+.
>
> On 21 February 2016 at
I can change it for the former (you need to use a string array, though),
the latter is only possible in Java 1.8+.
On 21 February 2016 at 22:22, Remko Popma wrote:
> Can an annotation have multiple values?
> @PerformanceSensitive("AllocationFree", "CriticalPath")
>
> Or can a method be annotated
Can an annotation have multiple values?
@PerformanceSensitive("AllocationFree", "CriticalPath")
Or can a method be annotated with the same annotation appear multiple times?
Both @PerformanceSensitive("AllocationFree")
and @PerformanceSensitive("CriticalPath")?
On Monday, 22 February 2016, Remko P
Using a generic annotation could work like @SuppressWarnings does.
On 21 February 2016 at 22:19, Remko Popma wrote:
> I like @PerformanceSensitive very much!
>
> I can then see specific variations like
> @PerformanceSensitive("InlineSize")
> @PerformanceSensitive("AllocationFree")
>
>
>
> Sent f
I like @PerformanceSensitive very much!
I can then see specific variations like
@PerformanceSensitive("InlineSize")
@PerformanceSensitive("AllocationFree")
Sent from my iPhone
> On 2016/02/22, at 12:48, Gary Gregory wrote:
>
> Well, a method can be on the critical path and not have been hand
Well, a method can be on the critical path and not have been hand-optimized
either because it is already as fast as can be or we have not gotten around
to it (which make you want to have a @NeedsOptimization, rabbit hole
warning!). So we could have both. Some methods would be @CriticalPath, and
som
Those both sound better, but I can't decide on which.
On 21 February 2016 at 21:32, Gary Gregory wrote:
> I wonder if @CriticalPath or @HandOptimized would convey better what we
> are trying to express?
>
> Gary
>
>
> -- Forwarded message --
> From:
> Date: Sun, Feb 21, 2016 at
