author | Marcel M. Cary <marcel@oak.homeunix.org> | |
Wed, 18 Feb 2009 03:00:43 +0000 (19:00 -0800) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Fri, 20 Feb 2009 06:49:55 +0000 (22:49 -0800) | ||
commit | 7d233dea5f4e299fdac8d6cfb610bcd4d60a82b7 | |
tree | 0db846c08686796a39fd9b10d321b30127ff60ee | tree | snapshot |
parent | 024aa7d8d5114f76e616a0ed8ddcf3b463ff2c14 | commit | diff |
gitweb: Hyperlink multiple git hashes on the same commit message line
The current implementation only hyperlinks the first hash on
a given line of the commit message. It seems sensible to
highlight all of them if there are multiple, and it seems
plausible that there would be multiple even with a tidy line
length limit, because they can be abbreviated as short as 8
characters.
Benchmark:
I wanted to make sure that using the 'e' switch to the Perl regex
wasn't going to kill performance, since this is called once per commit
message line displayed.
In all three A/B scenarios I tried, the A and B yielded the same
results within 2%, where A is the version of code before this patch
and B is the version after.
1: View a commit message containing the last 1000 commit hashes
2: View a commit message containing 1000 lines of 40 dots to avoid
hyperlinking at the same message length
3: View a short merge commit message with a few lines of text and
no hashes
All were run in CGI mode on my sub-production hardware on a recent
clone of git.git. Numbers are the average of 10 reqests per second
with the first request discarded, since I expect this change to affect
primarily CPU usage. Measured with ApacheBench.
Note that the web page rendered was the same; while the new code
supports multiple hashes per line, there was at most one per line.
The primary purpose of scenarios 2 and 3 were to verify that the
addition of 1000 commit messages had an impact on how much of the time
was spent rendering commit messages. They were all within 2% of 0.80
requests per second (much faster).
So I think the patch has no noticeable effect on performance.
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current implementation only hyperlinks the first hash on
a given line of the commit message. It seems sensible to
highlight all of them if there are multiple, and it seems
plausible that there would be multiple even with a tidy line
length limit, because they can be abbreviated as short as 8
characters.
Benchmark:
I wanted to make sure that using the 'e' switch to the Perl regex
wasn't going to kill performance, since this is called once per commit
message line displayed.
In all three A/B scenarios I tried, the A and B yielded the same
results within 2%, where A is the version of code before this patch
and B is the version after.
1: View a commit message containing the last 1000 commit hashes
2: View a commit message containing 1000 lines of 40 dots to avoid
hyperlinking at the same message length
3: View a short merge commit message with a few lines of text and
no hashes
All were run in CGI mode on my sub-production hardware on a recent
clone of git.git. Numbers are the average of 10 reqests per second
with the first request discarded, since I expect this change to affect
primarily CPU usage. Measured with ApacheBench.
Note that the web page rendered was the same; while the new code
supports multiple hashes per line, there was at most one per line.
The primary purpose of scenarios 2 and 3 were to verify that the
addition of 1000 commit messages had an impact on how much of the time
was spent rendering commit messages. They were all within 2% of 0.80
requests per second (much faster).
So I think the patch has no noticeable effect on performance.
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb/gitweb.perl | diff | blob | history |