[ https://issues.apache.org/jira/browse/SOLR-14586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17144558#comment-17144558 ]
Noble Paul commented on SOLR-14586: ----------------------------------- There is no need to rush on this. if anything, this probably is a micro-optimization in most cases > replace the second function parameter in Map#computeIfAbsent with static vars > ----------------------------------------------------------------------------- > > Key: SOLR-14586 > URL: https://issues.apache.org/jira/browse/SOLR-14586 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Noble Paul > Assignee: Noble Paul > Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > continuing discussion from SOLR-14579 > consider the following > {code:java} > mapObject.computeIfAbsent(key, o -> new HashMap<>()); > {code} > vs. > {code:java} > mapObject.computeIfAbsent(key, Utils.NEW_HASHMAP_FUN) > {code} > > The first code fragment is executed as following > {code:java} > s.computeIfAbsent(key, new Function() { > @Override > public Object apply(String key) { > return new HashMap<>(); > } > } > {code} > So, there are two problems with this > * A new anonymous inner class is created for that lambda. This one extra > class becomes a part of your binary > * a new instance of that class is created everytime the > {{computeIfAbsent()}} method is invoked, irrespective of whether the value is > absent for that key or not. Now imagine that method getting called millions > of times and creating millions of such objects for no reason > OTOH > when I use {{Utils.NEW_HASHMAP_FUN}} > * Only a single anonymous class is created for the entire codebase > * Only single instance of that object is created in the VM > Ideally, we should go all over the codebase and remove such lambdas -- 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