From: "Lukas Sandström" <lukass@etek.chalmers.se>
To: Alex Riesen <raa.lkml@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <junkio@cox.net>
Subject: Re: [PATCH] speedup allocation in pack-redundant.c
Date: Wed, 23 Nov 2005 00:55:07 +0100 [thread overview]
Message-ID: <4383AFDB.90907@etek.chalmers.se> (raw)
In-Reply-To: <20051122233845.GC2916@steel.home>
Alex Riesen wrote:
> Lukas Sandström, Wed, Nov 23, 2005 00:14:53 +0100:
>
>>>>I think making allocation/deallocation to the central place is a
>>>>good cleanup, but I am not sure about the free-nodes reusing.
>>>>Does this make difference in real life?
>>>
>>>It definitely does, though nor very much. I have no real numbers at
>>>hand (being home now), but I remember it was 1 min with against 3 min
>>>without the patch on cygwin+fat32, which is already bad enough all by
>>>itself. Very big repository with no redundant packs in it.
>>
>>Would you mind sharing the .idx files?
>
>
> this time I probably would (they're not here)... But for a perfomance
> testing any big repository will do, linux kernel, for example.
>
The problem is that the large repository I have contains lots of
redundant packs, which makes quite fast to find a complete set
and end the search. If you don't have any redundant packs, the
complete set search really is 2**n (n = the number of packs).
I did some quick experiments with slab allocation and got a 4.4%
improvement on the redundant repo, so that might be worth persuing.
(Concept patch below)
diff --git a/pack-redundant.c b/pack-redundant.c
index b38baa9..05294f8 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -8,6 +8,8 @@
#include "cache.h"
+#define BLKSIZE 1024
+
static const char pack_redundant_usage[] =
"git-pack-redundant [ --verbose ] [ --alt-odb ] < --all | <.pack filename> ...>";
@@ -38,24 +40,28 @@ struct pll {
static struct llist_item *free_nodes = NULL;
+static inline void llist_item_put(struct llist_item *item)
+{
+ item->next = free_nodes;
+ free_nodes = item;
+}
+
static inline struct llist_item *llist_item_get()
{
struct llist_item *new;
if ( free_nodes ) {
new = free_nodes;
free_nodes = free_nodes->next;
- } else
- new = xmalloc(sizeof(struct llist_item));
-
+ } else {
+ int i = 1;
+ new = xmalloc(sizeof(struct llist_item) * BLKSIZE);
+ for(;i < BLKSIZE; i++) {
+ llist_item_put(&new[i]);
+ }
+ }
return new;
}
-static inline void llist_item_put(struct llist_item *item)
-{
- item->next = free_nodes;
- free_nodes = item;
-}
-
static void llist_free(struct llist *list)
{
while((list->back = list->front)) {
next prev parent reply other threads:[~2005-11-22 23:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-22 14:56 [PATCH] speedup allocation in pack-redundant.c Alex Riesen
2005-11-22 20:41 ` Junio C Hamano
2005-11-22 22:48 ` Lukas Sandström
2005-11-22 23:08 ` Junio C Hamano
2005-11-22 23:46 ` Alex Riesen
2005-11-22 23:00 ` Alex Riesen
2005-11-22 23:14 ` Lukas Sandström
2005-11-22 23:38 ` Alex Riesen
2005-11-22 23:55 ` Lukas Sandström [this message]
2005-11-23 7:31 ` Alex Riesen
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=4383AFDB.90907@etek.chalmers.se \
--to=lukass@etek.chalmers.se \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=raa.lkml@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.