lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stanislav Livotov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-12699) make LTRScoringModel immutable (to allow hashCode caching)
Date Tue, 04 Sep 2018 17:19:00 GMT

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

Stanislav Livotov edited comment on SOLR-12699 at 9/4/18 5:18 PM:
------------------------------------------------------------------

Hi, [~eribeiro] thanks for comments and review. In the attached patch I had fixed all your
comments. 

 

[~cpoerschke], I also can not imagine why someone would want to change the model after construction.
So from my POV, there is no need to support mutability.  Anyway, he will still be able to
do it with extending this class and overriding hashcode methods. 

 

About changing Supplier.memorize on computing hashCode in the constructor. Supplier.memorize
was working as lazy hashCode caching. And I think we need to support it for the case when
someone will have to add one more parameter which is not the part of current and which should
also influence hashCode calculation. In such case, this new field won't be initialized at
the moment when calculateHashCode will be executed in the super constructor call.

I've attached a patch based on your latest,  with just switching on lazy hashCode calculation
and fixes for [~eribeiro] comments. 


was (Author: slivotov):
Hi, [~eribeiro] thanks for comments and review. In the attached patch I had fixed all your
comments. 

 

Christine Poerschke, I also can not imagine why someone would want to change the model after
construction. So from my POV, there is no need to support mutability.  Anyway, he will still
be able to do it with extending this class and overriding hashcode methods. 

 

About changing Supplier.memorize on computing hashCode in the constructor. Supplier.memorize
was working as lazy hashCode caching. And I think we need to support it for the case when
someone will have to add one more parameter which is not the part of current and which should
also influence hashCode calculation. In such case, this new field won't be initialized at
the moment when calculateHashCode will be executed in the super constructor call.

I've attached a patch based on your latest,  with just switching on lazy hashCode calculation
and fixes for [~eribeiro] comments. 

> make LTRScoringModel immutable (to allow hashCode caching)
> ----------------------------------------------------------
>
>                 Key: SOLR-12699
>                 URL: https://issues.apache.org/jira/browse/SOLR-12699
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: contrib - LTR
>            Reporter: Stanislav Livotov
>            Priority: Major
>         Attachments: SOLR-12699.patch, SOLR-12699.patch, SOLR-12699.patch
>
>
> [~slivotov] wrote in SOLR-12688:
> bq. ... LTRScoringModel was a mutable object. It was leading to the calculation of hashcode
on each query, which in turn can consume a lot of time ... So I decided to make LTRScoringModel
immutable and cache hashCode calculation. ...
> (Please see SOLR-12688 description for overall context and analysis results.)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message