Skip to content

Flyweight support of key re-used objects #3940

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 2 commits into from
Closed

Flyweight support of key re-used objects #3940

wants to merge 2 commits into from

Conversation

bbakerman
Copy link
Member

@bbakerman bbakerman commented Apr 29, 2025 •
edited
Loading

I wanted to see if flyweight objects could be used for two very commonly created "cache key" objects, namely CacheKey and FieldCoordinates

This results in WAY less objects being allocated when they are used over and over with the same values. So this is a nett saving in memory in a a called system that is loading the same logical objects over and over. And this is likely to always be the case.

HOWEVER the thing happening here in terms of speed is

  • how fast can Java allocate a new object
  • vs
  • how fast can it do 2 or 3 map lookups

And the answer to that is that new Java objects are 361% faster than map lookups.

So this becomes a trade off between objects being allocated and cpu throughput

And its not worth taking - we should not merge this PR

However I wanted to create the PR to show my working

Benchmark                                                                      Mode  Cnt      Score     Error   Units
FlyWeightBenchmark.benchMarkDirectInstantiationThroughput                     thrpt    9    134.741 ±   0.299  ops/ms

FlyWeightBenchmark.benchMarkDirectInstantiationThroughput:gc.alloc.rate       thrpt    9   9251.771 ±  20.519  MB/sec
FlyWeightBenchmark.benchMarkDirectInstantiationThroughput:gc.alloc.rate.norm  thrpt    9  72000.029 ±   0.023    B/op
FlyWeightBenchmark.benchMarkDirectInstantiationThroughput:gc.count            thrpt    9   1400.000            counts
FlyWeightBenchmark.benchMarkDirectInstantiationThroughput:gc.time             thrpt    9    692.000                ms

FlyWeightBenchmark.benchMarkUsingFlyweightsThroughput                         thrpt    9     29.223 ±   0.761  ops/ms

FlyWeightBenchmark.benchMarkUsingFlyweightsThroughput:gc.alloc.rate           thrpt    9   2006.581 ±  52.273  MB/sec
FlyWeightBenchmark.benchMarkUsingFlyweightsThroughput:gc.alloc.rate.norm      thrpt    9  72000.132 ±   0.121    B/op
FlyWeightBenchmark.benchMarkUsingFlyweightsThroughput:gc.count                thrpt    9    596.000            counts
FlyWeightBenchmark.benchMarkUsingFlyweightsThroughput:gc.time                 thrpt    9    238.000                ms

FlyWeightBenchmark.benchMarkDirectInstantiationAvgTime                         avgt    9      0.008 ±   0.001   ms/op

FlyWeightBenchmark.benchMarkDirectInstantiationAvgTime:gc.alloc.rate           avgt    9   9071.949 ± 245.016  MB/sec
FlyWeightBenchmark.benchMarkDirectInstantiationAvgTime:gc.alloc.rate.norm      avgt    9  72000.042 ±   0.018    B/op
FlyWeightBenchmark.benchMarkDirectInstantiationAvgTime:gc.count                avgt    9   1154.000            counts
FlyWeightBenchmark.benchMarkDirectInstantiationAvgTime:gc.time                 avgt    9    805.000                ms

FlyWeightBenchmark.benchMarkUsingFlyweightsAveTime                             avgt    9      0.035 ±   0.001   ms/op

FlyWeightBenchmark.benchMarkUsingFlyweightsAveTime:gc.alloc.rate               avgt    9   1974.576 ±  72.272  MB/sec
FlyWeightBenchmark.benchMarkUsingFlyweightsAveTime:gc.alloc.rate.norm          avgt    9  72000.123 ±   0.133    B/op
FlyWeightBenchmark.benchMarkUsingFlyweightsAveTime:gc.count                    avgt    9    586.000            counts
FlyWeightBenchmark.benchMarkUsingFlyweightsAveTime:gc.time                     avgt    9    287.000                ms

Note here how its much slower in cpu terms but much more efficient in memory terms with a lot less GC happening

@bbakerman bbakerman added Not to be merged spikes or other stuff that should never or not yet to be merged performance work that is primarily targeted as performance improvements labels Apr 29, 2025
@github-actions GitHub Actions
Copy link
Contributor

Test Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit 03ca8a4.

bbakerman
bbakerman commented Apr 29, 2025
View reviewed changes
src/jmh/java/benchmark/BenchmarkUtils.java
@@ -81,4 +83,7 @@ private static int getRunForMillis() {
}
}

public static Blackhole blackHole() {
return new Blackhole("Today's password is swordfish. I understand instantiating Blackholes directly is dangerous.");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those crazy JMH people!

@bbakerman bbakerman mentioned this pull request Apr 29, 2025
Open
@bbakerman bbakerman closed this May 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
Not to be merged spikes or other stuff that should never or not yet to be merged performance work that is primarily targeted as performance improvements
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@bbakerman