• Bug
  • Status: Resolved
  • 2 Major
  • Resolution: Fixed
  • ehcache-core
  • rism
  • Reporter: lerm
  • November 30, 2015
  • 0
  • Watchers: 6
  • February 12, 2016
  • February 12, 2016

Attachments

Description

We’ve discovered that there exists a massive objects allocation in method BruteForceSearchManager.getCombinedExtractors during query execution. This method is called for every element in cache during search and combines both static and dynamic data extractors:

``` private Map<String, AttributeExtractor> getCombinedExtractors(Map<String, AttributeExtractor> configExtractors, DynamicAttributesExtractor dynIndexer, Element element) { Map<String, AttributeExtractor> combinedExtractors = new HashMap<String, AttributeExtractor>(); combinedExtractors.putAll(configExtractors);

    if (dynIndexer != null) { ...
            AttributeExtractor old = combinedExtractors.put(entry.getKey(), new AttributeExtractor() { ...
    }
    return combinedExtractors;
} ```

However, if dynamic extractors are not specified for particular cache, then allocation of new HashMap with copy of all the configured extractors is not required, thus it can be removed in such case:

private Map<String, AttributeExtractor> getCombinedExtractors(Map<String, AttributeExtractor> configExtractors, DynamicAttributesExtractor dynIndexer, Element element) { if (dynIndexer != null) { Map<String, AttributeExtractor> combinedExtractors = new HashMap<String, AttributeExtractor>(); combinedExtractors.putAll(configExtractors); ... AttributeExtractor old = combinedExtractors.put(entry.getKey(), new AttributeExtractor() { ... return combinedExtractors; } else { return configExtractors; } }

We’ve made a small JMH test ([attached|^ehtest-benchmark.zip]) to test proposed [fix|^BruteForceSearchManager.java] - searching objects among 500K elements. Tests were executed with and without fix (using command ‘-f 1 -i 10 -bm avgt -prof gc’). Here are the results (running on Core i3-4130): {noformat}Before fix: Benchmark Mode Cnt Score Error Units CacheTest.testSearch avgt 10 0,292 ? 0,012 s/op CacheTest.testSearch:·gc.alloc.rate.norm avgt 10 152 394 528,600 ? 8385,450 B/op

After fix: Benchmark Mode Cnt Score Error Units CacheTest.testSearch avgt 10 0,166 ? 0,001 s/op CacheTest.testSearch:·gc.alloc.rate.norm avgt 10 24 393 720,419 ? 4809,227 B/op{noformat}

So, introducing of this fix resulted in 5x decrease of objects allocation rate (152M -> 24M) and ~2x increase in search performance (292 ms -> 166 ms).

Comments

James House 2016-01-13

Hi Alexey,

In order to accept your patch/contribution, could you please submit a signed contributor agreement as described here: http://www.ehcache.org/community/contribute.html

Alexey Makhmutov 2016-01-16

Hi James,

I’ve just sent the signed contributor agreement to the [email protected].

Fiona OShea 2016-01-18

Assigning to Louis to verify Alexey’s patch. A signed contributor agreement has been received from Alexey.

Louis Jacomet Jacomet 2016-01-20

Thanks Alexey for the report and the contribution.

This has been applied on trunk and merged back on 2.9.x and 2.8.x lines.

I will close once testing confirms this does not cause any problem.

Rishabh Monga 2016-02-12

Tested