← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to bzrlib/_static_tuple_c.c

  • Committer: John Arbash Meinel
  • Date: 2009-10-12 18:02:07 UTC
  • mto: This revision was merged to the branch mainline in revision 4736.
  • Revision ID: john@arbash-meinel.com-20091012180207-gqjvwo80raq23gvq
Some comment cleanup, implement a special case for Py_EQ when both objects are intrened.

btree_mem_test.py doesn't show a significant impact. Real-world we probably
only use Py_EQ comparisons in sets and dicts when we get conflicts, also
note that we *don't* do the comparison for StaticTuple_Intern() because the
objects haven't been interned yet...

However, it seems 'correct' to do the check, so I'll leave it in.

Show diffs side-by-side

added added

removed removed

Lines of Context:
bzrlib/_static_tuple_c.c
364
364
            return Py_False;
365
365
        }
366
366
    }
367
 
    /* TODO: if STATIC_TUPLE_INTERNED_FLAG is set on both objects and they are
368
 
     *       not the same pointer, then we know they aren't the same object
369
 
     *       without having to do sub-by-sub comparison.
370
 
     */
 
367
    if (op == Py_EQ
 
368
        && _StaticTuple_is_interned(v_st)
 
369
        && _StaticTuple_is_interned(w_st))
 
370
    {
 
371
        /* If both objects are interned, we know they are different if the
 
372
         * pointer is not the same, which would have been handled by the
 
373
         * previous if. No need to compare the entries.
 
374
         */
 
375
        Py_INCREF(Py_False);
 
376
        return Py_False;
 
377
    }
371
378
 
372
379
    /* The only time we are likely to compare items of different lengths is in
373
380
     * something like the interned_keys set. However, the hash is good enough
559
566
};
560
567
 
561
568
/* TODO: Implement StaticTuple_as_mapping.
562
 
 * The only thing we really want to support from there is mp_subscript, so that
563
 
 * we could support extended slicing (foo[::2]). Not worth it yet, though.
 
569
 *       The only thing we really want to support from there is mp_subscript,
 
570
 *       so that we could support extended slicing (foo[::2]). Not worth it
 
571
 *       yet, though.
564
572
 */
565
573
 
566
574