[
https://issues.apache.org/jira/browse/LUCENE-10180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430575#comment-17430575
]
Uwe Schindler edited comment on LUCENE-10180 at 10/19/21, 2:20 PM:
-------------------------------------------------------------------
{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 bytecode without
creating a method out of it (and then make a reference to the same type of
method reference syntax in the lambda bootstrap invokedynamic). 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).
was (Author: thetaphi):
{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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
