git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Robert Fitzsimons <robfitz@273k.net>
Cc: Martin Langhoff <martin.langhoff@gmail.com>,
	Linus Torvalds <torvalds@osdl.org>, Jeff Garzik <jeff@garzik.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Rogan Dawes <discard@dawes.za.net>,
	Kernel Org Admin <ftpadmin@kernel.org>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: read-for-fill and caching in gitweb (Re: kernel.org mirroring)
Date: Fri, 29 Dec 2006 11:40:45 +0100	[thread overview]
Message-ID: <200612291140.46909.jnareb@gmail.com> (raw)
In-Reply-To: <20061229032126.GE6558@localhost>

Robert Fitzsimons wrote:

> Here are the mean (and standard deviation) in milliseconds for those
> pages using a few different versions of gitweb.
> 
>                  project_list   summary  shortlog        log
> v267                  173 1.6  1141 8.8   795 5.0   919  1.9
> 1.4.4.3               220 2.3   397 2.4   930 4.2  1113 56.9
> 1.5.0.rc0.g4a4d       226 1.9   292 1.7   352 4.0   491  6.7
> 1.5.0.rc0.g4a4d        60 1.0   131 0.7   195 1.2   347  3.7
> (mod_perl)

> I'll look into the increase in time for the project_list in more recent
> versions of gitweb, tomorrow.

It is simply the case that new features cost more. Namely in earlier
versions of gitweb Last Change time was taken from HEAD (from current
branch), in newer we check all branches (using git-for-each-ref).
For published public repository it migh make sense to pack also heads
(make them packed refs).

I was thinking about making this a gitweb %feature, allowing gitweb
administrator to chose if Last Change is taken from all branches
(as it is now), from HEAD (as it was before), or from given branch
(for example master).

Another thing that might made small increase in time is checking
if project is to be visible to gitweb ($export_ok and $strict_export).

-- 
Jakub Narebski
Poland

  reply	other threads:[~2006-12-29 10:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-28 20:45 read-for-fill and caching in gitweb (Re: kernel.org mirroring) Martin Langhoff
2006-12-29  3:21 ` Robert Fitzsimons
2006-12-29 10:40   ` Jakub Narebski [this message]
2006-12-29 11:46     ` Martin Langhoff
2006-12-29 12:47       ` Jakub Narebski
2006-12-29 19:31     ` Robert Fitzsimons

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

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

  git send-email \
    --in-reply-to=200612291140.46909.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=discard@dawes.za.net \
    --cc=ftpadmin@kernel.org \
    --cc=git@vger.kernel.org \
    --cc=hpa@zytor.com \
    --cc=jeff@garzik.org \
    --cc=martin.langhoff@gmail.com \
    --cc=robfitz@273k.net \
    --cc=torvalds@osdl.org \
    /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.
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 NNTP newsgroup(s).