git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 2/3] fast-export: improve speed by skipping blobs

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
May 6, 2013, 19:09 UTC
Message-ID
<CAMP44s2rdkND40QDQA9T7MNGoKPtnr50nV98aExUe4bCOXZGyA@mail.gmail.com>
In-Reply-To
<7v7gjctabm.fsf@alter.siamese.dyndns.org>
On Mon, May 6, 2013 at 10:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 18 quoted lines
> Jeff King <peff@peff.net> writes:
>
>> On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote:
>>
>>> We don't care about blobs, or any object other than commits, but in
>>> order to find the type of object, we are parsing the whole thing, which
>>> is slow, specially in big repositories with lots of big files.
>>
>> I did a double-take on reading this subject line and first paragraph,
>> thinking "surely fast-export needs to actually output blobs?".
>>
>> Reading the patch, I see that this is only about not bothering to load
>> blob marks from --import-marks. It might be nice to mention that in the
>> commit message, which is otherwise quite confusing.
>
> I had the same reaction first, but not writing the blob _objects_
> out to the output stream would not make any sense, so it was fairly
> easy to guess what the author wanted to say ;-).
That's how fast-export has worked since --export-marks was introduced.
Show 13 quoted lines
>> I'm also not sure why your claim "we don't care about blobs" is true,
>> because naively we would want future runs of fast-export to avoid having
>> to write out the whole blob content when mentioning the blob again.
>
> The existing documentation is fairly clear that marks for objects
> other than commits are not exported, and the import-marks codepath
> discards anything but commits, so there is no mechanism for the
> existing fast-export users to leave blob marks in the marks file for
> later runs of fast-export to take advantage of.  The second
> invocation cannot refer to such a blob in the first place.
>
> The story is different on the fast-import side, where we do say we
> dump the full table and a later run can depend on these marks.
Yes, and gaining nothing but increased disk-space.
Show 7 quoted lines
> By discarding marks on blobs, we may be robbing some optimization
> possibilities, and by discarding marks on tags, we may be robbing
> some features, from users of fast-export; we might want to add an
> option "--use-object-marks={blob,commit,tag}" or something to both
> fast-export and fast-import, so that the former can optionally write
> marks for non-commits out, and the latter can omit non commit marks
> if the user do not need them. But that is a separate issue.

How? The only way we might rob optimizations is if there's an obscene amount files, otherwise the number of blob marks that we are *actually* going to use ever again is extremely tiny.

-- 
Felipe Contreras
Previous: Felipe ContrerasNext: Junio C Hamano
Message 17 of 25 in “fast-export: speed improvements”
  1. 0/3 fast-export: speed improvementsFelipe Contreras, May 5, 2013
  2. 1/3 fast-{import,export}: use get_sha1_hex() directlyFelipe Contreras, May 5, 2013
  3. Junio C HamanoMay 7, 2013
  4. Felipe ContrerasMay 7, 2013
  5. Junio C HamanoMay 7, 2013
  6. 2/3 fast-export: improve speed by skipping blobsFelipe Contreras, May 5, 2013
  7. Jeff KingMay 6, 2013
  8. Junio C HamanoMay 6, 2013
  9. Junio C HamanoMay 6, 2013
  10. Jeff KingMay 6, 2013
  11. Junio C HamanoMay 6, 2013
  12. Jeff KingMay 6, 2013
  13. Junio C HamanoMay 6, 2013
  14. Jeff KingMay 6, 2013
  15. Jeff KingMay 6, 2013
  16. Felipe ContrerasMay 6, 2013
  17. Felipe ContrerasMay 6, 2013
  18. Junio C HamanoMay 6, 2013
  19. Felipe ContrerasMay 6, 2013
  20. Junio C HamanoMay 7, 2013
  21. Felipe ContrerasMay 7, 2013
  22. Felipe ContrerasMay 6, 2013
  23. Jeff KingMay 6, 2013
  24. Felipe ContrerasMay 6, 2013
  25. 3/3 fast-export: don't parse all the commitsFelipe Contreras, May 5, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.