You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The fastcache in pathdb is used to cache clean trie nodes in memory, aiming to reduce database reads and improve performance. Given that the operating system will also use all available memory for the OS page cache, it’s interesting to compare the performance differences between these two caching mechanisms.
There is no big difference between these two caching mechanisms.
I have deployed the benchmarks for 163 hours, the master branch (fastcache) is 3hours ahead. In another word, it's 1.8% faster than the experimental branch (os native cache)
There are approximately 30 billion node retrievals in total, with 2.5 billion of these retrievals being hits in the clean cache. This means that 8.3% of node retrievals are handled by fastcache.
The average speed difference between os native cache and fastcache is 4.32 microsecond, which is neglibible.
The performance difference can also be reflected in account update and triedb commit. The experimental branch spends 0.7ms more on account update and 0.6ms less on triedb commit. The former comes from the clean cache hitting and the latter one comes from the overhead of clean cache insertion and eviction.
I think we can conclude that the performance gain of using fastcache is very limited (considering the overhead of cache maintaining). It might be reasonable to remove the clean cache in total.
The text was updated successfully, but these errors were encountered:
The fastcache in pathdb is used to cache clean trie nodes in memory, aiming to reduce database reads and improve performance. Given that the operating system will also use all available memory for the OS page cache, it’s interesting to compare the performance differences between these two caching mechanisms.
There is no big difference between these two caching mechanisms.
I have deployed the benchmarks for 163 hours, the master branch (fastcache) is 3hours ahead. In another word, it's 1.8% faster than the experimental branch (os native cache)
There are approximately 30 billion node retrievals in total, with 2.5 billion of these retrievals being hits in the clean cache. This means that 8.3% of node retrievals are handled by fastcache.
The average speed difference between os native cache and fastcache is 4.32 microsecond, which is neglibible.
The performance difference can also be reflected in
account update
andtriedb commit
. The experimental branch spends 0.7ms more onaccount update
and 0.6ms less ontriedb commit
. The former comes from the clean cache hitting and the latter one comes from the overhead of clean cache insertion and eviction.I think we can conclude that the performance gain of using fastcache is very limited (considering the overhead of cache maintaining). It might be reasonable to remove the clean cache in total.
The text was updated successfully, but these errors were encountered: