# Ideas for a JIT optimizer

**URL:** <https://www.ruby-forum.com/t/ideas-for-a-jit-optimizer/169993>\
**Category:** Ruby\
**Created:** [June 11, 2009, 1:23am UTC](https://www.ruby-forum.com/t/ideas-for-a-jit-optimizer/169993 "2009-06-11T01:23:03Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\
**Post date:** [June 11, 2009, 1:23am UTC](https://www.ruby-forum.com/t/ideas-for-a-jit-optimizer/169993/1 "2009-06-11T01:23:03Z")

</div>

Currently I am thinking that an optimizer that takes

class A  
def one\_thing  
calls\_another 3  
end  
def calls\_another a  
a.to\_s  
end  
end

and converts it to C, such that one\_thing calls another _in c_ would be  
a good JIT.

ex:  
VALUE  
one\_thing\_in\_c(VALUE self) {  
return calls\_another(NUM2FIX(3));  
}

VALUE to\_s = rb\_intern(“to\_s”);  
VALUE calls\_another(VALUE self, VALUE in) {  
return rb\_funcall(in, to\_s);  
}

Any thoughts on this? Ideas? Suggestions?  
This seems to be the next step for ruby2cext (which almost does this,  
but not quite).  
Thanks much.  
-=r

---

<div class="post-metadata">

**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\
**Post date:** [June 11, 2009, 2:47am UTC](https://www.ruby-forum.com/t/ideas-for-a-jit-optimizer/169993/2 "2009-06-11T02:47:36Z")

</div>

On Wed, Jun 10, 2009 at 6:23 PM, Roger P.[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> and converts it to C, such that one\_thing calls another _in c_ would be  
> a good  JIT.

It would be _one way_ to jit, but it would not allow for polymorphism  
(multiple target types providing the same method) or any redefinition.  
Nor would it easily allow for methods to be defined at runtime, so  
you’d need to make sure both methods exist and choose to statically  
bind them (setting that binding in stone) for all time. In this case,  
where you’re doing a “self” call, as long as there’s no subclass and  
no method changes at runtime, it’s probably ok. But of course you  
don’t know if it will stay that way forever.

- Charlie