Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
> I'm a bit suspicious of the massive speed up I'm seeing by avoiding
> the default format but it appears to be repeatable.
This is interesting. The default format over just 'x' is to
concatenate the refname with hexadecimal form of the object name,
while (at least as the code originally was intended):
* the cost of parsing the "--format=<format>" string into series of
atoms is one-time O(1), and there is nothing specially tricky in
there.
* the cost of computing these atoms should be miniscule, as
in the default format, the per-ref cost come from these:
- populate_value() -> get_refname() -> show_ref() for the refname
would merely be a xstrdup() of the refname.
- populate_value() -> grab_oid() -> do_grab_oid() should be using
O_FULL so there shouldn't be any find_unique_abbrev() cost.
Just binary-to-hex.
- populate_value() -> get_object() -> oid_object_info_extended() ->
grab_common_values() asks for ATOM_OBJECTTYPE that should be a
single xstrdup(), but oid_object_info_extended() needs to parse
the object, but .info.contentp ought to be NULL and we should
not be calling parse_object_buffer().
So it might be worth looking into where the time is going (didn't
Peff or somebody do that a few years ago, though?) when using the
default format and optimize or special case the codepath, but the
responses I have seen from two of you makes me suspect that the new
option is not the best general approach.
Thanks.
