Am 19.07.2014 18:43, schrieb brian m. carlson:
On Sat, Jul 19, 2014 at 02:11:30PM +0200, René Scharfe wrote:
I'd say if a platform doesn't bother optimizing memcmp() then they
deserve the resulting performance. And it's probably not too bad a
penalty because such comparisons probably won't make
On Sat, Jul 19, 2014 at 02:11:30PM +0200, René Scharfe wrote:
> I'd say if a platform doesn't bother optimizing memcmp() then they
> deserve the resulting performance. And it's probably not too bad a
> penalty because such comparisons probably won't make up a significant
> part of most application
Am 19.07.2014 01:57, schrieb Jeff King:
> On Fri, Jul 18, 2014 at 09:14:05PM +0200, René Scharfe wrote:
>
>> If inlining is really better is another matter; I don't understand how
>> 1a812f3a (hashcmp(): inline memcmp() by hand to optimize) could have made
>> git gc 18% faster, as it claimed. I w
On Fri, Jul 18, 2014 at 09:14:05PM +0200, René Scharfe wrote:
> If inlining is really better is another matter; I don't understand how
> 1a812f3a (hashcmp(): inline memcmp() by hand to optimize) could have made
> git gc 18% faster, as it claimed. I would expect memcmp(), which can
> compare more
Am 18.07.2014 20:42, schrieb Jonathan Nieder:
René Scharfe wrote:
Signed-off-by: Rene Scharfe
---
fast-import.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Before:
$ size git-fast-import
textdata bss dec hex filename
8041386768 754160 1565066
René Scharfe wrote:
> Signed-off-by: Rene Scharfe
> ---
> fast-import.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Before:
$ size git-fast-import
textdata bss dec hex filename
8041386768 754160 1565066 17e18a git-fast-import
After:
$ size git-fa
Signed-off-by: Rene Scharfe
---
fast-import.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fast-import.c b/fast-import.c
index fa635f7..d73f58c 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2324,7 +2324,7 @@ static void file_change_m(const char *p, struct branch *b)
7 matches
Mail list logo