On Wed, May 2, 2018 at 7:26 PM, Stefan Beller <sbel...@google.com> wrote: >> Another suggestion is object_pool, if we keep 'struct object' instead >> of 'struct parsed_object' and also want to keep current allocation >> behavior: no individual deallocation. If you free, you free the whole >> pool (e.g. you could run rev-list --all --objects in a separate pool, >> once you're done, you delete the whole pool). > > That is what the following patches will be about, you can > only free the whole set of parsed objects. > > So if you want to do a separate rev walk, you may need to > instantiate a new repository for it (ideally you'd only need a > separate parsed object store).
I'm not sure if it's a good idea to create a separate struct repository just because you want to free this parsed object store. What if updates are made in both repositories? All the cache (well, mostly the delta base cache in sha1_file.c) will double memory usage as well. Yeah not ideal. But I guess making rev-list related code use a separate parsed object store is no small task (and kinda risky as well since we migrate from global lookup_* functions to local ones and need to choose the correct parsed object store to look up from) For your information, there is already a good use case for this wholesale memory free: if we can free the rev-list related memory early in pack-objects (e.g. part of repack operation) then it could lower memory pressure significantly when running on large repos. This has been discussed a bit lately. -- Duy
