[ 
https://issues.apache.org/jira/browse/LUCENE-5640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13989404#comment-13989404
 ] 

Uwe Schindler commented on LUCENE-5640:
---------------------------------------

The MethodHandle code is also used to create the attributes in the 
DEFAULT_ATTRIBUTE_FACTORY. And this improves a lot in comparison to the old 
reflection based approach.

I am sorry for the first patch yesterday to be slower. In fact it was unfair, 
was just to late in the evening (4 am in the morning):
- I did not use invokeExact and because of that, unter the hood it used the 
similar code like reflection.
- The unfair part was that the stupid bug I had was to implicit use reflection 
to create the Token instance, and this was bad.
- With invokeExact its now identical to all code around for sorting and lists 
of Java 8. All code there uses the exact same pattern, generated by the javac 
compiler.
- Invokedynamic is not involved at all. Invokedynamic is something else, here 
we have hard linked ctor calls.

You standpoint is like forbidding this syntax in Java 8: {{Arrays.sort(array, 
Integer::compare);}} - this is heavily tested and as fast as 
{{Arrays.sort(array, new Comparator() \{ ... \};}}  This is just some hotspot 
noise.

It would be really nice (instead of complaining here about nonsense, sorry), if 
we could check the performance of this with non-packed AttributeImpls. E.g. for 
TokenStreams adding KeywordAttribute or PayloadAttribute or 
JapaneseFoobarAttribute. Here we should see a large improvement in contrast to 
old code. Or create a lot of FuzzyTermsEnums!

> Cleanup Token class
> -------------------
>
>                 Key: LUCENE-5640
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5640
>             Project: Lucene - Core
>          Issue Type: Sub-task
>          Components: modules/analysis
>            Reporter: Uwe Schindler
>             Fix For: 4.9, 5.0
>
>         Attachments: LUCENE-5640.patch, LUCENE-5640.patch, LUCENE-5640.patch, 
> LUCENE-5640.patch, LUCENE-5640.patch
>
>
> We should remove code duplication in the Token class:
> - copy constructors
> - reinit() shit
> - non-default clone()
> This is too bugy. Most of the methods can be simply removed. In fact, Token 
> should just look like a clone of all AttributeImpl it implements.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to