On Fri, May 03, 2013 at 02:02:44AM -0400, Jeff King wrote:
> > Can we be sure that the function is never invoked in concurrently from
> > different threads? I attempted to audit code paths, but quickly gave up
> > because I know too little about this machinery.
>
> I didn't check explicitly, but
On Fri, May 03, 2013 at 07:59:09AM +0200, Johannes Sixt wrote:
> Am 5/2/2013 17:46, schrieb Jeff King:
> > On Thu, May 02, 2013 at 09:05:01AM +0200, Johannes Sixt wrote:
> >> BTW, do you notice that the function is now modifying an object (the hash
> >> table) even though this is rather unexpected
Am 5/2/2013 17:46, schrieb Jeff King:
> On Thu, May 02, 2013 at 09:05:01AM +0200, Johannes Sixt wrote:
>> BTW, do you notice that the function is now modifying an object (the hash
>> table) even though this is rather unexpected from a "lookup" function?
>
> I think this is fine. The function is co
On Thu, May 02, 2013 at 08:46:08AM -0700, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > BTW, do you notice that the function is now modifying an object (the hash
> > table) even though this is rather unexpected from a "lookup" function?
>
> At the philosophical level, "lookup" ought to be
On Thu, May 02, 2013 at 09:05:01AM +0200, Johannes Sixt wrote:
> > I figured the lengthy description in the commit message would be
> > sufficient,
>
> It's absolutely sufficient *if* one reads the commit message. In this
> case, though it goes more like "this function should be trivial, and it i
Johannes Sixt writes:
> BTW, do you notice that the function is now modifying an object (the hash
> table) even though this is rather unexpected from a "lookup" function?
At the philosophical level, "lookup" ought to be operating on a
"const" table. But at the implementation level, the table do
Jeff King writes:
> I figured the lengthy description in the commit message would be
> sufficient, but I don't mind adding something like your suggestion to
> point readers of the code in the right direction when they see it.
Yeah, I'll squash J6t's comment in and requeue.
If somebody is learni
Am 5/2/2013 8:46, schrieb Jeff King:
> On Thu, May 02, 2013 at 08:44:07AM +0200, Johannes Sixt wrote:
>> Am 5/1/2013 22:34, schrieb Jeff King:
>>> struct object *lookup_object(const unsigned char *sha1)
>>> {
>>> - unsigned int i;
>>> + unsigned int i, first;
>>> struct object *obj;
>>>
On Thu, May 02, 2013 at 08:44:07AM +0200, Johannes Sixt wrote:
> Am 5/1/2013 22:34, schrieb Jeff King:
> > struct object *lookup_object(const unsigned char *sha1)
> > {
> > - unsigned int i;
> > + unsigned int i, first;
> > struct object *obj;
> >
> > if (!obj_hash)
> >
Am 5/1/2013 22:34, schrieb Jeff King:
> struct object *lookup_object(const unsigned char *sha1)
> {
> - unsigned int i;
> + unsigned int i, first;
> struct object *obj;
>
> if (!obj_hash)
> return NULL;
>
> - i = hashtable_index(sha1);
> + first = i =
Jeff King writes:
> We could instead bump X into the `i` slot, and then shift
> the whole contiguous chain down by one, resulting in:
>
> index | i-1 | i | i+1 | i+2 |
>---
> entry ... | A | X | B | C | ...
>---
The lookup_object function is backed by a hash table of all
objects we have seen in the program. We manage collisions
with a linear walk over the colliding entries, checking each
with hashcmp(). The main cost of lookup is in these
hashcmp() calls; finding our item in the first slot is
cheaper than
12 matches
Mail list logo
