From: Daniel DeLorme <dan-ml@dan42.com>
To: ruby-core@ruby-lang.org
Subject: Re: Copy-on-write friendly garbage collector
Date: Sat, 8 Mar 2008 14:34:10 +0900 [thread overview]
Message-ID: <47D2255C.2010205@dan42.com> (raw)
In-Reply-To: <E1JWASO-0001JU-Nn@x61.netlab.jp>
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;
}
next prev parent reply other threads:[~2008-03-08 5:35 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-03 9:48 Copy-on-write friendly garbage collector Hongli Lai
2008-03-03 12:38 ` Daniel DeLorme
2008-03-03 13:11 ` Yukihiro Matsumoto
2008-03-04 11:31 ` Gonzalo Garramuño
2008-03-07 12:04 ` Hongli Lai
2008-03-07 15:20 ` Paul Brannan
2008-03-07 16:22 ` Hongli Lai
2008-03-07 18:47 ` Joel VanderWerf
2008-03-08 5:34 ` Daniel DeLorme [this message]
2008-03-08 7:50 ` Daniel DeLorme
2008-03-08 10:01 ` Daniel DeLorme
2008-03-08 15:39 ` Yukihiro Matsumoto
2008-03-12 17:23 ` Hongli Lai
2008-03-12 17:38 ` Yukihiro Matsumoto
2008-03-13 0:48 ` Daniel DeLorme
2008-03-13 11:04 ` Hongli Lai
2008-03-15 16:15 ` Hongli Lai
2008-03-13 11:18 ` Hongli Lai
2008-03-14 3:20 ` Hongli Lai
2008-03-14 4:44 ` Daniel DeLorme
2008-03-14 11:25 ` Hongli Lai
2008-03-14 12:01 ` Meinrad Recheis
2008-03-14 15:00 ` Daniel Berger
2008-03-14 15:53 ` Hongli Lai
2008-03-14 17:34 ` Joel VanderWerf
2008-03-20 10:59 ` Hongli Lai
2008-03-20 11:55 ` Yukihiro Matsumoto
2008-03-20 12:54 ` Hongli Lai
2008-03-20 14:24 ` Yukihiro Matsumoto
2008-03-20 14:45 ` Hongli Lai
2008-03-20 15:28 ` Joel VanderWerf
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-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47D2255C.2010205@dan42.com \
--to=ruby-core@ruby-lang.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).