CaoManhDat edited a comment on issue #1395: SOLR-14365: CollapsingQParser - Avoiding always allocate int[] and float[] with size equals to number of unique values (WIP) URL: https://github.com/apache/lucene-solr/pull/1395#issuecomment-610985910 > The javadoc in the constructor is good, but I'm concerned that this util class may be used elsewhere without clearly reading/understanding the risk I'm not very concern about this point much. If we gonna put this class in guava or some places like that I think it is worth to spend more time to documents or make the api right. But these classes will get used in Solr and when they use `DynamicMaps` they must have a clear idea of what they gonna use. I just want to avoid introduce more logic to these classes since one change needs to propagate and maintain in others. > Did you test and debug when the DynamicMap upgrades from a map to an array internally? I mean in debug mode step by step here. I think the map first enlarges and rehashes just before the upgrade to an array. It seems that your calculation missed the part that arraySize must be powerOfTwo and `initialCapacity` is not equals to `expectedElements`. So I will go from backward with `arraySize=1024` -> `mapExpectedElements=768 (arraySize = expectedElements/0.75)` -> `threshold = 768 * 0.75 = 576` -> `resizeAt=768 (arraySize * loadFactor)` so we kinda safe here, right?
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
