From: Daniel DeLorme <dan-ml@...42.com>
Date: 2008-03-08T14:34:10+09:00
Subject: Re: Copy-on-write friendly garbage collector

Yukihiro Matsumoto wrote:
> Here's the patch against the latest trunk (r15675).  It's still 8-10%
> slower than the current implementation.

Matz, what do you consider would be an acceptable tradeoff in speed for 
the benefits of copy-on-write? Is 5% slower acceptable or does it *have* 
to match the current performance?

I tried my hand at optimization; assuming that
  1) a given object is more likely to be in one of the larger heaps,
  2) there are not enough heaps to justify the overhead of a bsearch,
I changed the bsearch to a linear search in the function below and found 
a slight performance improvement.



static inline struct heaps_slot *
find_heap_slot_for_object(RVALUE *object)
{
     struct heaps_slot *heap;
     register int i;

     /* Look in the cache first. */
     if (last_heap != NULL && object >= last_heap->slot
	&& object < last_heap->slot + last_heap->limit) {
	return last_heap;
     }
     /* find heap_slot for object using bsearch*/
     for(i=0; i<heaps_used; i++) {
	heap = &heaps[i];
	if (heap->slot <= object) {
	    if (object < heap->slot + heap->limit) {
		/* Cache this result. According to empirical evidence, the chance is
		 * high that the next lookup will be for the same heap slot.
		 */
		last_heap = heap;
		return heap;
	    }
	}
     }
     return NULL;
}