[
https://issues.apache.org/jira/browse/LUCENE-10180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430575#comment-17430575
]
Uwe Schindler commented on LUCENE-10180:
----------------------------------------
{quote}
bq. does the proposed solution (function pointers) make the profiles more
consistent?
Yes it does, since the method ref is always given its actual name in profiles.
{quote}
Background for [~sokolov]: Lambdas can't be compiled to without creating a
method out of it. So {{a -> foobar(a)}} will generate a static or virtual
method (depending on if access to "this" is needed) named {{lambda$XY(a)}} with
the body {{return foobar(a)}. This is of course not needed but you always see
the lambda method in the stack traces. So to better allow to see where
something happens in "simple cases" (does not work in complex chains with Java
streams): Avoid lambdas and add the bodies as methods. But always look at
signatures and always prefer a method reference anywhere in code if a lambda
that only calls another method with exact same parameter (with or without
"this" capture).
> Remove usage of lambdas in SegmentMerger?
> -----------------------------------------
>
> Key: LUCENE-10180
> URL: https://issues.apache.org/jira/browse/LUCENE-10180
> Project: Lucene - Core
> Issue Type: Wish
> Reporter: Adrien Grand
> Priority: Minor
> Fix For: main (9.0)
>
> Attachments: profile.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SegmentMerger now uses lambdas to share the logic around logging merging
> times for all file formats.
> One problem is that these lambdas get auto-generated names, and it makes it
> harder to work with profilers since things that should logically end up in
> the same sub tree end up in different sub trees because two instances of the
> same lambda get different names.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
