Re: read-for-fill and caching in gitweb (Re: kernel.org mirroring)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]