RCR 172: Some way to precompile classes in extensions
Submitted by legacy (Fri Nov 28 08:11:49 UTC 2003)
Abstract
This is a legacy RCR from Ruby Garden, submitted by dmiceman. Matz has declared these RCRs obsolete, and asked that their authors resubmit them in the new format.
I think what adding thousands methods in hundreds classes when loading big extensions like fox is too much overhead. May be it is possible to precompile them in some sort of C structures with smaller processor time?
Problem
(RCR imported from old format)
Proposal
Analysis
(RCR imported from old format)
Implementation
(RCR imported from old format)
You don't quote any figures to back up what you say. How does the overhead of adding all the ruby methods compare with the overhead of loading the large C++ libs that the extensions wrap?
A way of avoiding the startup overhead in ruby is to dynamically despatch the method calls via method_missing, class_method_missing and const_method_missing. This is the approach taken by the QtRuby and KDE ruby bindings that I'm working on. The combined Qt/KDE api has 800+ classes and 20000+ methods, but the start up speed is limited by the size of the shared library to be loaded. If the lib already loaded, startup is quite fast.
-- Richard
|
| Strongly opposed |
0 |
| Opposed |
0 |
| Neutral |
0 |
| In favor |
0 |
| Strongly advocate |
0 |
|
RCRchive copyright © David Alan Black, 2003-2005.
Powered by .
Re: Some way to precompile classes in extensions (richard_dale, 2003-11-28 13:49:29)
A way of avoiding the startup overhead in ruby is to dynamically despatch the method calls via method_missing, class_method_missing and const_method_missing. This is the approach taken by the QtRuby and KDE ruby bindings that I'm working on. The combined Qt/KDE api has 800+ classes and 20000+ methods, but the start up speed is limited by the size of the shared library to be loaded. If the lib already loaded, startup is quite fast.
-- Richard