git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <christian.couder@gmail.com>
To: ZheNing Hu <adlternative@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Hariom verma <hariom18599@gmail.com>,
	Git List <git@vger.kernel.org>
Subject: Re: [GSoC] Git Blog 11
Date: Mon, 2 Aug 2021 08:25:35 +0200	[thread overview]
Message-ID: <CAP8UFD16pqERdF4Mdq=_ktvFB1rcXwB9PRy8TjNq=ThH5HbeqA@mail.gmail.com> (raw)
In-Reply-To: <CAOLTT8RwwMF07f=XxWN=zGsPU0VQ8FqPVdyepQp78Ei8WZpSrw@mail.gmail.com>

On Sun, Aug 1, 2021 at 8:45 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> My eleventh week blog finished:
> The web version is here:
> https://adlternative.github.io/GSOC-Git-Blog-11/

Great, thanks!

> ### Attempt to optimize performance
>
> This week, at the prompt of my mentor Christian, I used `gprof` for some
> performance tests about `git cat-file --batch`:
> [Re: [GSOC] How to improve the performance of git cat-file --batch]
> (https://lore.kernel.org/git/CAOLTT8TdL7UhfVSOzbpmo-WFNrcKwmy=E720tNt4KM9o_p=keg@mail.gmail.com/)

[...]

> Here is an amazing fact:
>
> The number of calls to `lookup_object()` before and after using my
> patch are 0 and
> 522709 respectively. Therefore, I am very surprised, why do we have
> these additional calls?

> After printing the call stack of `lookup_object()`, we can know that
> the `parse_buffer()`
> is calling them.

s/the `parse_buffer()`/`parse_buffer()`/

or

s/the `parse_buffer()`/the `parse_buffer()` function/

Also: s/them/it/

> A very straightforward idea, can we avoid calling
> this function?
>
> In `parse_object_buffer()`, `parse_blob_buffer()`, ``parse_tree_buffer()`,
> `parse_commit_buffer()`, and `parse_tag_buffer()` parse the object

s/parse/we parse/

> data, and then store
> it in `struct object *obj`, finally return it to the caller.

Maybe: s/finally/and finally/

> `get_object()` will feed the `obj` to `grab_values()`, and then
> `grab_values()` will feed the
> `obj` to `grab_tag_values()`, `grab_commit_values()`, which can fill
> the object info in `obj` to
> implement some atom, e.g. `%(tag)`, `%(type)`, `%(object)`, `%(tree)`,
> `%(numparent)`,`%(parent)`.
> It is worth noting that `%(objectname)`, `%(objecttype)`,
> `%(objectsize)`, `%(deltabase)`, `%(rest)`,
> `%(raw)` are did not appear in them, this means that we can avoid

s/are did not/don't/

> parsing object buffer when we
> don't use those atoms which require `obj`'s information!
>
> After some processing and adaptation, I made the patch which can skip

s/the patch/a patch/

> `parse_object_buffer()`
> in some cases, this is the result of the performance test of
> `t/perf/p1006-cat-file.sh`:
>
> ```
> Test                                        HEAD~             HEAD
> ------------------------------------------------------------------------------------
> 1006.2: cat-file --batch-check              0.10(0.09+0.00)
> 0.11(0.10+0.00) +10.0%
> 1006.3: cat-file --batch-check with atoms   0.09(0.08+0.01)
> 0.09(0.06+0.03) +0.0%
> 1006.4: cat-file --batch                    0.62(0.58+0.04)
> 0.57(0.54+0.03) -8.1%
> 1006.5: cat-file --batch with atoms         0.63(0.60+0.02)
> 0.52(0.49+0.02) -17.5%
> ```
>
> We can see that the performance of `git cat-file --batch` has been a
> certain improvement!

Yeah, sure -8.1% or -17.5% is really nice! But why +10.0% for
`cat-file --batch-check`?

> Tell a joke: removing 1984531500 if checking can reduce the startup
> time of GTA5 by 70%. :-D

s/if checking/checks/

As this joke refers to:

https://rockstarintel.com/a-fan-reduces-gta-online-loading-times-by-70

it might be nice to add a link to help people like me who didn't know
about this and had to google it.

> Currently the patch has not been submitted to the mailing list, let us
> wait a bit...

Looking forward to it...

  reply	other threads:[~2021-08-02  6:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-01  6:46 [GSoC] Git Blog 11 ZheNing Hu
2021-08-02  6:25 ` Christian Couder [this message]
2021-08-03  2:37   ` ZheNing Hu
2021-08-03  2:49     ` ZheNing Hu
2021-08-04  8:56       ` Christian Couder
2021-08-05  4:50         ` ZheNing Hu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP8UFD16pqERdF4Mdq=_ktvFB1rcXwB9PRy8TjNq=ThH5HbeqA@mail.gmail.com' \
    --to=christian.couder@gmail.com \
    --cc=adlternative@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hariom18599@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).