[PATCH 2 of 2 LOG-SPEED-FIX] repoview: cache filtered changelog

Pierre-Yves David pierre-yves.david at ens-lyon.org
Sat Jan 19 00:39:27 UTC 2013


On 18 janv. 2013, at 23:49, Pierre-Yves David wrote:

> # HG changeset patch
> # User Pierre-Yves David <pierre-yves.david at logilab.fr>
> # Date 1358549012 -3600
> # Node ID 8de68237ff6885eac13b2c1d64eb3ad8c4cae562
> # Parent  b6f71d62f8f7a1fb027891ee0acee2e3a015d8b9
> repoview: cache filtered changelog
> 
> Creating a new changelog object for each access is costly and prevents efficient
> caching changelog side. This introduced a x5 performance regression in log
> because chunk read from disk were never reused. We were jumping from about 100
> disk read to about 20 000.
> 
> This changeset introduce a simple cache mechanism that help the last changelog
> object created by a repoview. The changelog is reused until the changelog or the
> filtering changes.
> 
> The cache invalidation is much more complicated than it should be. But MQ test
> show a strange cache desync. I was unable to track down the source of this
> desync in descent time so I'm not sure if the issue is in MQ or core. However
> given the proximity to the 2.5 freeze, I'm choosing the inelegant but safe route
> that makes the cache mechanism safer.

The Siddharth Agarwal fix for atime (ecba9b0e7672) does not help to remove the crazyness of MQ

-- 
Pierre-Yves


More information about the Mercurial-devel mailing list