Hi there,
I think I found a few nasty problems with racy detection, as well as
performance issues when using git implementations with different file
time resolutions on the same repository (e.g. git compiled with and
without USE_NSEC, libgit2 compiled with and without USE_NSEC, JGit
executed in di
fixes racy detection in USE_NSEC-enabled git with
core.checkStat=minimal, as the coreStat setting now affects racy checks as
well.
Finally, do not check ctime if ctime.sec is 0 (as recorded by JGit).
Signed-off-by: Karsten Blees
---
read-ca
Am 28.09.2015 um 14:52 schrieb Johannes Schindelin:
> Otherwise there would be that little loop-hole where (nsec % 1000) == 0 *by
> chance* and we assume the timestamps to be identical even if they are not.
Yeah, but in this case the file would be racy, as racy-checks use
the same comparison now.
Am 28.09.2015 um 19:38 schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> Problem 1: Failure to detect racy files (without USE_NSEC)
>> ==
>>
>> Git may not detect racy changes when 'update-index'
very small, to get a
better estimate.
Signed-off-by: Karsten Blees
---
git-gui/lib/database.tcl | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/git-gui/lib/database.tcl b/git-gui/lib/database.tcl
index 1f187ed..212b195 100644
--- a/git-gui/lib/database.tcl
++
established UTF-8 NFC as de-facto standard
for path names.
Update the documentation in i18n.txt to reflect the current status-quo.
Signed-off-by: Karsten Blees
---
Documentation/i18n.txt | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/Docu
Signed-off-by: Karsten Blees
---
Enabling nanosecond file times was recently discussed on the libgit2 project, so
I thought its time to fix the nanosecond issue on Linux. Don't know yet if the
patch will be accepted (and in which kernel version).
Considering that nanosecond file times are
Am 15.06.2015 um 02:12 schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt
>> index e9a1d5d..e5f6233 100644
>> --- a/Documentation/i18n.txt
>> +++ b/Documentation/i18n.txt
>> @@ -1,18 +1,28 @@
>
Renaming to an existing file doesn't work on Windows network shares if the
target file is open.
munmap() the old config file before commit_lock_file.
Signed-off-by: Karsten Blees
---
See https://github.com/git-for-windows/git/issues/226
Strangely, renaming to an open file works fine on
Signed-off-by: Karsten Blees
---
...just changed wording as you suggested.
Documentation/technical/racy-git.txt | 8 ++--
Makefile | 9 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/technical/racy-git.txt
b
established UTF-8 NFC as de-facto standard
for path names.
Update the documentation in i18n.txt to reflect the current status-quo.
Signed-off-by: Karsten Blees
---
Sorry for the delay, got swamped with other stuff...
Am 17.06.2015 um 22:45 schrieb Junio C Hamano:
>
> ... I am OK to
Am 23.07.2015 um 16:53 schrieb Konstantin Khomoutov:
> On Thu, 23 Jul 2015 11:14:11 +0200
> Konrád Lőrinczi wrote:
>
> [...]
>> I accept these solutions as workarounds, but the real solution would
>> be: Dev suggestions:
>> 1) Add a --force-reread option to git status, so user can force
>> reread
Am 16.03.2016 um 17:39 schrieb Alexander Kuleshov:
> There is common pattern to traverse a hashmap in git source code:
>
> hashmap_iter_init(map, &iter);
> while ((entry = hashmap_iter_next(&iter)))
> // do something with entry
>
The hashmap_iter_first() function al
Am 17.03.2016 um 11:38 schrieb Alexander Kuleshov:
> This patch introduces the for_each_hashmap_entry() macro for more
I'd rather call it 'hashmap_for_each', following the pattern
'operandtype_operation' used throughout git. E.g. we already have
'hashmap_get', not 'get_hashmap_entry'.
I realize
Am 13.02.2014 00:03, schrieb Mike Hommey:
> On Wed, Feb 12, 2014 at 12:00:19PM +0100, Karsten Blees wrote:
>> Am 12.02.2014 04:43, schrieb Duy Nguyen:
>>> On Wed, Feb 12, 2014 at 9:02 AM, Robin H. Johnson
>>> wrote:
>>>> On Tue, Feb 11, 2014 at 05:54:51PM
Am 13.02.2014 19:38, schrieb Zachary Turner:
> The only reason ReOpenFile is necessary at
> all is because some code somewhere is mixing read-styles against the same
> fd.
>
I don't understand...ReadFile with OVERLAPPED parameter doesn't modify the
HANDLE's file position, so you should be abl
xed read
> styles, but it seems like the only possible explanation.
>
> On Thu, Feb 13, 2014 at 2:53 PM, Stefan Zager wrote:
>> On Thu, Feb 13, 2014 at 2:51 PM, Karsten Blees
>> wrote:
>>> Am 13.02.2014 19:38, schrieb Zachary Turner:
>>>
>>>> The onl
Am 14.02.2014 20:16, schrieb Zachary Turner:
> For the mixed read, we wouldn't be looking for another caller of
> pread() (since it doesn't care what the file pointer is), but instead
> a caller of read() or lseek() (since those do depend on the current
> file pointer). In index-pack.c, I see two
Am 27.02.2014 21:32, schrieb Torsten Bögershausen:
> On 2014-02-27 20.50, Junio C Hamano wrote:
>> Lee Hopkins writes:
>>
>>> Last week I ran across a potential bug with branch names on case
>>> insensitive file systems, the complete scenario can be found here:
>>>
>>> https://groups.google.com/fo
Am 28.02.2014 07:41, schrieb Johannes Sixt:
> Am 2/28/2014 0:38, schrieb Lee Hopkins:
>>> If I understand the issue correctly, the problem is that packed-refs
>>> are always case-sensitive, even if core.ignorecase=true. OTOH,
>
> core.ignorecase is intended to affect filenames of the worktree, not
Am 01.03.2014 07:54, schrieb Torsten Bögershausen:
> On 2014-03-01 03.42, Lee Hopkins wrote:
>> +
>> +if(ignore_case)
> Only looking at ignore_case here closes the door for people
> who have a branch "foo" and "Foo" at the same time.
> (Which means that they are carefully running git pack-refs)
Am 03.03.2014 18:51, schrieb Junio C Hamano:
> Lee Hopkins writes:
>
>> I went ahead and took a stab at a solution. My solution is more
>> aggressive than a warning, I actually prevent the creation of
>> ambiguous refs. My changes are also in refs.c, which may not be
>> appropriate, but it seemed
Am 10.03.2014 12:42, schrieb Dennis Luehring:
> Am 10.03.2014 12:28, schrieb demerphq:
>> I had the impression, and I would not be surprised if they had the
>> impression that the git development community is relatively
>> unconcerned about performance issues on larger repositories.
>
> so the que
Am 10.03.2014 12:00, schrieb Michael Haggerty:
>
> Reference transactions
> --
>
Very cool ideas indeed.
However, I'm concerned a bit that transactions are conceptual overkill. How
many concurrent updates do you expect in a repository? Wouldn't a single
repo-wide lock suff
Am 19.03.2014 01:46, schrieb sza...@chromium.org:
> This adds a Windows implementation of pread. Note that it is NOT
> safe to intersperse calls to read() and pread() on a file
> descriptor.
This is a bad idea. You're basically fixing the multi-threaded issue twice,
while at the same time breaki
Am 20.03.2014 17:08, schrieb Stefan Zager:
> On Thu, Mar 20, 2014 at 6:54 AM, Karsten Blees
> wrote:
>> Am 19.03.2014 01:46, schrieb sza...@chromium.org:
>>> This adds a Windows implementation of pread. Note that it is NOT
>>> safe to intersperse calls t
Am 20.03.2014 02:25, schrieb Duy Nguyen:
> On Thu, Mar 20, 2014 at 4:35 AM, Stefan Zager wrote:
>> This adds a Windows implementation of pread. Note that it is NOT
>> safe to intersperse calls to read() and pread() on a file
>> descriptor. According to the ReadFile spec, using the 'overlapped'
>
Am 21.03.2014 06:35, schrieb Stefan Zager:
> On Thu, Mar 20, 2014 at 10:21 PM, Duy Nguyen wrote:
>> On Fri, Mar 21, 2014 at 08:51:18AM +0700, Duy Nguyen wrote:
>>> On Thu, Mar 20, 2014 at 11:08 PM, Stefan Zager wrote:
Duy, would you like to re-post your patch without the new pread
impl
Am 20.03.2014 22:56, schrieb Stefan Zager:
> On Thu, Mar 20, 2014 at 2:35 PM, Karsten Blees
> wrote:
>> Am 20.03.2014 17:08, schrieb Stefan Zager:
>>
>>> Going forward, there is still a lot of performance that gets left on
>>> the table when you rule out thr
Am 09.04.2014 18:43, schrieb Felipe Contreras:
> Junio C Hamano wrote:
>> - To officially adopt the logo that appears on the "project
>>home page" as our "project logo".
>
> I have made my objections to that logo before, but here it goes again: bright
> red is a horrible color for a logo, as
Am 29.08.2014 19:40, schrieb Keller, Jacob E:
> On Fri, 2014-08-29 at 19:26 +0200, Johannes Sixt wrote:
>> Am 29.08.2014 18:42, schrieb Jacob Keller:
>>> From: Jonas 'Sortie' Termansen
>>>
>>> This function will be used in a following commit.
>>>
>>> The timer_settime function is provided in librt
Am 17.04.2014 07:51, schrieb Nguyễn Thái Ngọc Duy:
> This patch serves as a heads up about a feature I'm working on. I hope
> that by posting it early, people could double check if I have made
> some fundamental mistakes that completely ruin the idea. It's about
> speeding up "git status" by cachin
Am 22.04.2014 12:35, schrieb Duy Nguyen:
> On Tue, Apr 22, 2014 at 5:13 PM, Duy Nguyen wrote:
>>> IIRC name_hash.c::lazy_init_name_hash took ~100ms on my system, so
>>> hopefully you did a dummy 'cache_name_exists("anything")' before starting
>>> the measurement of the first run?
>>
>> No I didn
Am 29.04.2014 11:12, schrieb Marat Radchenko:
> On MinGW, compat/mingw.h defines a 'mingw_main' wrapper function.
> Fix `warning: passing argument 2 of 'mingw_main' from incompatible
> pointer type` in http-fetch.c and remote-curl.c by dropping 'const'.
>
Would you mind cross checking your change
This is the POSIX port of the patches I typically use to track down msysgit
performance issues (thus v4, the latest windows-only version is here [1]).
Sebastian and Dscho thought this might be useful in core git, so here it is.
[1] https://github.com/msysgit/git/pull/46
Karsten Blees (3):
add
case (measure repetitive code sections):
uint64_t t = 0;
for (;;) {
/* ignore */
t -= getnanotime();
/* code section to measure */
t += getnanotime();
/* ignore */
}
trace_performance(t, "frotz");
Signed-off-by: Karsten Blees
---
cache
following platforms:
* Linux: using clock_gettime(CLOCK_MONOTONIC)
* Windows: using QueryPerformanceCounter()
Todo:
* enable clock_gettime() on more platforms
* implement Mac OSX version using mach_absolute_time
Signed-off-by: Karsten Blees
---
Makefile | 7 +
cache.h
' 'config'
'--get-color' 'color.interactive.help' 'red bold'
performance: at trace.c:319, time: 0.000280701 s: git command: 'git' 'config'
'--get-color' '' 'reset'
performance: at trace.c:319, time: 0.00
Am 21.05.2014 09:31, schrieb Noel Grandin:
> On 2014-05-20 21:11, Karsten Blees wrote:
>> * implement Mac OSX version using mach_absolute_time
>>
>>
>
>
> Note that unlike the Windows and Linux APIs, mach_absolute_time does not do
> correction for frequency
Am 21.05.2014 18:58, schrieb Jeff King:
> On Tue, May 20, 2014 at 09:11:19PM +0200, Karsten Blees wrote:
>
>> Add trace_performance and trace_performance_since macros that print file
>> name, line number, time and an optional printf-formatted text to the file
>> specified
Am 21.05.2014 18:55, schrieb Jeff King:
> On Tue, May 20, 2014 at 09:11:24PM +0200, Karsten Blees wrote:
>
>> Add performance tracing to identify which git commands are called and how
>> long they execute. This is particularly useful to debug performance issues
>&
Am 22.05.2014 00:14, schrieb Richard Hansen:
> On 2014-05-20 15:11, Karsten Blees wrote:
>> Add a getnanotime() function that returns nanoseconds since 01/01/1970 as
>> unsigned 64-bit integer (i.e. overflows in july 2554).
>
> Must it be relative to epoch? If it was re
Am 22.05.2014 11:59, schrieb Jeff King:
> On Thu, May 22, 2014 at 02:40:48AM +0200, Karsten Blees wrote:
>
>> E.g. if I'm interested in a particular code section, I throw in 2
>> lines of code (before and after the code section). This gives very
>> accurate r
Am 02.06.2014 18:43, schrieb Steve Hoelzer:
> There is consensus that the default should change because it will
> benefit nearly all users (some just a little, but some a lot).
> See [1] and replies.
Git for Windows users may want to try core.fscache=true as well [1]. This
eliminates the UAC pena
Am 03.06.2014 08:18, schrieb Steve Hoelzer:
> On Mon, Jun 2, 2014 at 3:01 PM, Karsten Blees wrote:
>> Git for Windows users may want to try core.fscache=true as well [1]. This
>> eliminates the UAC penalties for repositories located on the Windows system
>> drive
Am 04.06.2014 16:05, schrieb Erik Faye-Lund:
> On Wed, Jun 4, 2014 at 3:47 PM, Duy Nguyen wrote:
>> On Wed, Jun 4, 2014 at 6:47 PM, Stepan Kasal wrote:
>>> @@ -133,7 +133,7 @@ char *git_path(const char *fmt, ...)
>>> void home_config_paths(char **global, char **xdg, char *file)
>>> {
>>>
Am 04.06.2014 17:46, schrieb Johannes Schindelin:
> Hi kusma,
>
> On Wed, 4 Jun 2014, Johannes Schindelin wrote:
>
>> The problem arises whenever git.exe calls subprocesses. You can pollute
>> the environment by setting HOME, I do not recall the details, but I
>> remember that we had to be very c
Am 05.06.2014 10:03, schrieb Stepan Kasal:
> From: Johannes Schindelin
> Date: Wed, 2 Jun 2010 00:41:33 +0200
>
> If HOME is not set, use $HOMEDRIVE$HOMEPATH
>
> Signed-off-by: Johannes Schindelin
> Signed-off-by: Stepan Kasal
> ---
>
> Hello Karsten,
> thanks for your explanation. There are
Am 05.06.2014 14:03, schrieb Johannes Schindelin:
> Hi Karsten,
>
> On Thu, 5 Jun 2014, Karsten Blees wrote:
>
>> After a bit of digging in the history and the old googlegroups issue
>> tracker, I think this patch is completely unrelated to the non-ASCII
>> problems
Am 05.06.2014 10:05, schrieb Stepan Kasal:
> mingw.c defines several wrapper functionsi, like mingw_unlink().
> These wrappers are deployed by macros like this:
> #define unlink mingw_unlink
> The function itself is preceded by #undef, leaving the wrapper out
> of the game for the rest of min
Am 05.06.2014 15:39, schrieb Johannes Schindelin:
> And in particular with your changes to Unicodify the complete environment,
> I am *highly* doubtful that child processes will be able to handle
> themselves properly, unless we spend a whole lot of time converting back
> and forth the environment
Am 05.06.2014 11:58, schrieb Erik Faye-Lund:
> On Thu, Jun 5, 2014 at 11:40 AM, Karsten Blees
> wrote:
>> Am 05.06.2014 10:03, schrieb Stepan Kasal:
>>> From: Johannes Schindelin
>>> Date: Wed, 2 Jun 2010 00:41:33 +0200
>>>
>>> If HOME is not se
Am 05.06.2014 18:56, schrieb Johannes Sixt:
> Am 05.06.2014 10:05, schrieb Stepan Kasal:
>> mingw.c defines several wrapper functionsi, like mingw_unlink().
>> These wrappers are deployed by macros like this:
>> #define unlink mingw_unlink
>> The function itself is preceded by #undef, leaving
Am 05.06.2014 17:13, schrieb Stepan Kasal:
> Hello Karsten,
>
> On Thu, Jun 05, 2014 at 04:51:39PM +0200, Karsten Blees wrote:
>> In the current msysgit HEAD, most of these #undef's can simply be
>> removed or have already been removed [...]
>
> not "most of
Am 06.06.2014 10:32, schrieb Stepan Kasal:
> Hello,
>
> On Fri, Jun 06, 2014 at 12:00:51AM +0200, Karsten Blees wrote:
>> Am 05.06.2014 18:56, schrieb Johannes Sixt:
>>> Within mingw.c, if some other function inside mingw.c wants to use
>>> mingw_unlink, then it s
Am 29.05.2014 12:47, schrieb Stepan Kasal:
> Fix const warnings in http-fetch.c and remote-curl.c main() where is
> argv declared as const.
>
> The fix should work for all future declarations of main, no matter
> whether the second parameter's type is "char**", "const char**", or
> "char *[]".
I'
Am 06.06.2014 15:43, schrieb Stepan Kasal:
> Hello,
>
> This is a series of dirent modifications, 4 tiny ones and one bigger.
> As the date indicates, these are battle tested in mysgit for several years.
>
The dates are actually missing from the patches, otherwise full ack from me.
Thanks!
--
in.
> The fourth one is just a trivial prerequisite for
> the last one, that was written in Jan 2012, with a fixup from Mar 2012.
>
The dates are missing from the patches.
It would also have been nice to name (or link to) the patches you sqashed.
> Regards,
> Stepan
>
&g
Am 05.06.2014 08:06, schrieb Heiko Voigt:
> This allows a reader to immediately know which options can be used and
> what this parameter is about.
>
[...]
> -void hashmap_free(struct hashmap *map, int free_entries)
> +void hashmap_free(struct hashmap *map, enum hashmap_free_options
> free_entries
Am 06.06.2014 13:10, schrieb Stepan Kasal:
> Hi Karsten,
>
> On Fri, Jun 06, 2014 at 11:43:03AM +0200, Karsten Blees wrote:
>> Thinking about this some more, the best solution is probably to
>> eliminate the problem altogether by adding inline-wrappers for
>>
Am 06.06.2014 21:13, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> Am 29.05.2014 12:47, schrieb Stepan Kasal:
>>> Fix const warnings in http-fetch.c and remote-curl.c main() where is
>>> argv declared as const.
>>>
>>> The fix should wor
Am 06.06.2014 23:29, schrieb Peter Krefting:
> Stepan Kasal:
>
>> +/* only called from console_thread, so a static buffer will do */
>> +static wchar_t wbuf[2 * BUFFER_SIZE + 1];
>
> Wouldn't BUFFER_SIZE + 1 (or even BUFFER_SIZE) do here? If you convert from
> up to BUFFER_SIZE octets of
.649779 git.c:312] trace: built-in: git 'rev-parse' '--git-dir'
Or print file:line at the end (but what about multi-line messages, such as
packet-trace?):
> GIT_TRACE=1 git stash list
00:12:10.544266 trace: exec: 'git-stash' 'list' (git.c:512)
00:12:10.
Also include direct dependencies (strbuf.h and git-compat-util.h for
__attribute__) so that trace.h can be used independently of cache.h, e.g.
in test programs.
Signed-off-by: Karsten Blees
---
cache.h | 13 ++---
trace.h | 17 +
2 files changed, 19 insertions(+), 11
trace_printf_key() is the only non-static function that duplicates the
printf format attribute in the .c file, remove it for consistency.
Signed-off-by: Karsten Blees
---
trace.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/trace.c b/trace.c
index 37a7fa9..3e31558 100644
--- a/trace.c
The format parameter to trace_printf functions is sometimes abbreviated
'fmt'. Rename to 'format' everywhere (consistent with POSIX' printf
specification).
Signed-off-by: Karsten Blees
---
trace.c | 22 +++---
trace.h | 2 +-
2 files changed, 12 in
formatting.
Signed-off-by: Karsten Blees
---
trace.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/trace.c b/trace.c
index 3e31558..b7ca51b 100644
--- a/trace.c
+++ b/trace.c
@@ -62,6 +62,21 @@ static int get_trace_fd(const char *key
an print arbitrary binary data (without barfing on
'%' or stopping at '\0'), so 'data' seems more appropriate.
Signed-off-by: Karsten Blees
---
trace.c | 45 ++---
trace.h | 2 +-
2 files changed, 35 insertions(+), 12 deletio
processes are involved).
Signed-off-by: Karsten Blees
---
trace.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/trace.c b/trace.c
index c920429..5a3393a 100644
--- a/trace.c
+++ b/trace.c
@@ -79,12 +79,21 @@ static void do_trace_print(const char *key, const struct
No functional changes, just move stuff around so that the next patch isn't
that ugly...
Signed-off-by: Karsten Blees
---
trace.c | 36 ++--
trace.h | 12
2 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/trace.c b/trace.c
index 5a
2005+ (_MSC_VER 1400). This has the nice side effect that the old
C-style declarations serve as documentation how the macros are to be used.
Signed-off-by: Karsten Blees
---
git-compat-util.h | 4
trace.c | 69 +--
tr
ion, e.g. using mach_absolute_time + mach_timebase_info
Signed-off-by: Karsten Blees
---
Makefile | 7 +
config.mak.uname | 1 +
trace.c | 82
trace.h | 1 +
4 files changed, 91 insertions(+)
diff --git a/Makefile b/Makefil
rformance(t, "frotz");
Signed-off-by: Karsten Blees
---
trace.c | 49 +
trace.h | 24
2 files changed, 73 insertions(+)
diff --git a/trace.c b/trace.c
index 4bd52f2..0551509 100644
--- a/trace.c
+++ b/trace.c
@
7 s: git command: 'git'
'config' '--get-color' 'color.interactive.help' 'red bold'
23:57:38.650465 trace.c:405 performance: 0.000243063 s: git command: 'git'
'config' '--get-color' '' 'reset'
23:57:38.6548
Am 11.06.2014 10:01, schrieb Karsten Blees:
> the epoch allows using the results (div 10e9) with other time-related APIs.
s/10e9/1e9/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo
Am 10.06.2014 12:17, schrieb Heiko Voigt:
> On Fri, Jun 06, 2014 at 07:52:03PM +0200, Karsten Blees wrote:
>> Am 05.06.2014 08:06, schrieb Heiko Voigt:
>>> This allows a reader to immediately know which options can be used and
>>> what this parameter is about.
>>
pping the handles
in MSVCRT's internal data structures, as we do in winansi_init().
Reported-by: Johannes Sixt
Signed-off-by: Karsten Blees
---
Thanks for reporting this.
The fix applies on top of [6/6] Win32: fix broken pipe detection (should
probably not be squashed, as its obviously
Am 12.06.2014 21:12, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> Am 10.06.2014 12:17, schrieb Heiko Voigt:
>>> The intention of Jonathans critique here[1] was that you do not see what
>>> this parameter does on the callsite. I.e.:
>>>
>>>
Am 11.06.2014 11:37, schrieb Stepan Kasal:
> This is the second part of the time-proven unicode suport branch from msysgit.
> This batch is a collection of small independent changes, limited to mingw.c.
> The only exception is the last patch: it changes gitk and git-gui.
>
I'm missing the other t
Am 17.06.2014 19:11, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> Simple use case (measure one code section):
>>
>> uint64_t start = getnanotime();
>> /* code section to measure */
>> trace_performance_since(start, "foobar");
>>
&
Am 17.06.2014 18:44, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> Am 11.06.2014 10:01, schrieb Karsten Blees:
>>> the epoch allows using the results (div 10e9) with other time-related APIs.
>>
>> s/10e9/1e9/
>
> That replacement is fine but the &q
Am 12.06.2014 20:30, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> Here's v5 of the performance tracing patch series, now including a bunch of
>> cleanups and adding timestamp, file and line to all trace output.
>>
>> I'm particularly interested in
Also include direct dependencies (strbuf.h and git-compat-util.h for
__attribute__) so that trace.h can be used independently of cache.h, e.g.
in test programs.
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
cache.h | 13 ++---
trace.h | 17 +
2 files
e_performance[_since]() return value and the
respective usage example. Renamed trace_performance_vfl to
trace_performance_vprintf_fl.
The other patches are the versions from pu.
Karsten Blees (11):
trace: move trace declarations from cache.h to new trace.h
trace: consiste
trace_printf_key() is the only non-static function that duplicates the
printf format attribute in the .c file, remove it for consistency.
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
trace.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/trace.c b/trace.c
index 37a7fa9
The format parameter to trace_printf functions is sometimes abbreviated
'fmt'. Rename to 'format' everywhere (consistent with POSIX' printf
specification).
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
trace.c | 22 +++---
trace.h |
formatting.
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
trace.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/trace.c b/trace.c
index 3e31558..b7ca51b 100644
--- a/trace.c
+++ b/trace.c
@@ -62,6 +62,21 @@ static int
processes are involved).
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
trace.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/trace.c b/trace.c
index 9fa406e..9fa6cc7 100644
--- a/trace.c
+++ b/trace.c
@@ -81,6 +81,10 @@ static int trace_bare = -1
al file IO).
While we're at it, rename trace_strbuf's 'buf' argument, which suggests
that the function is modifying the buffer. Trace_strbuf() currently is the
only trace API that can print arbitrary binary data (without barfing on
'%' or stopping at '\0'), so
No functional changes, just move stuff around so that the next patch isn't
that ugly...
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
trace.c | 36 ++--
trace.h | 12
2 files changed, 26 insertions(+), 22 deletions(-)
diff --
er (currently there are 30 *.c files of length 18 and just 11 of 19).
Trace output from longer source files (e.g. builtin/receive-pack.c) will
not be aligned.
Signed-off-by: Karsten Blees
---
git-compat-util.h | 4
trace.c | 72 +
h_absolute_time + mach_timebase_info
Signed-off-by: Karsten Blees
Signed-off-by: Junio C Hamano
---
Makefile | 7 +
config.mak.uname | 1 +
trace.c | 82
trace.h | 1 +
4 files changed, 91 insertions(+)
diff --g
/* ignore */
}
trace_performance(t, "frotz");
Signed-off-by: Karsten Blees
---
trace.c | 47 +++
trace.h | 18 ++
2 files changed, 65 insertions(+)
diff --git a/trace.c b/trace.c
index 88e05b9..65cd887 100644
--- a/trace.c
+++ b/trace.c
@@ -1
7 s: git command: 'git'
'config' '--get-color' 'color.interactive.help' 'red bold'
23:57:38.650465 trace.c:405 performance: 0.000243063 s: git command: 'git'
'config' '--get-color' '' 'reset'
23:57:38.654
Am 21.06.2014 00:33, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> To be able to add a common prefix or suffix to all trace output (e.g.
>> a timestamp or file:line of the caller), factor out common setup and
>> cleanup tasks of the trace* functions.
>>
>&
Am 21.06.2014 00:49, schrieb Philip Oakley:
> Should there be some documentation as well? Perhaps in t/README, or in
> Documentation/howto.
I'll add Documentation/technical/api-trace.txt when I find the time.
But lets settle on the final API first.
--
To unsubscribe from this list: send the line "
Putting the new trace_performance functions to good use, here are a few
observations about git-status performance.
Comes with three patches (mostly independent, not a patch series!):
* [PATCH] preload-index: optimize for sequential IO
Improves preload-index performance, should apply anywhere
by path, this implicitly increases IO locality.
This improves cold cache performance of preload_index() by ~20% and
hot cache performance by ~15%. Total improvement of e.g. 'git status -uno'
on WebKit is ~15% (cold cache) and ~5% (hot cache).
Signed-off-by: Karsten Blees
---
preload-in
IO).
Signed-off-by: Karsten Blees
---
Applies on top of "preload-index: optimize for sequential IO".
preload-index.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/preload-index.c b/preload-index.c
index 6ac368d..5fe5521 100644
--- a/prelo
Add trace_performance output to functions involved in git-status.
Signed-off-by: Karsten Blees
---
Applies on top of performance-tracing topic.
builtin/commit.c | 8
preload-index.c | 4
read-cache.c | 2 ++
wt-status.c | 11 +++
4 files changed, 25
1 - 100 of 383 matches
Mail list logo
