Hi Mark, As macrubyc's compilation logic is essentially spawning several command-line tools, I wonder if calling the logic directly from macruby_deploy is going to bring significant advantages, vs the complexity of splitting macrubyc.
I think a better strategy would be to optimize what's slow in macrubyc (such as command-line options parsing), and better include the compilation strategy into Xcode (if possible). Laurent On Mar 12, 2011, at 5:40 PM, Mark Rada wrote: > Hi, > > I have completed a proof of concept patch for MacRuby where I have split the > UI of macrubyc from the underlying logic so that tools like macruby_deploy > can make use of the compiler without having to spawn a new macruby process > for each file that needs to be compiled. This should also be beneficial for > compiling gems and the standard library. > > After having made this patch, I realized that there are still several places > in the compiler where a new process is spawned to perform part of the > compilation. I'm not really sure how much else can be lib-ified from the > other required components. Overall there are still a few places that I know I > can optimize without much work needed. > > Right now, compile time for ruby files with about 100-200 lines of code is > about 1(+/-0.1) seconds on my MBP. Spawning a new macruby process and > processing the macrubyc options takes about 0.25 seconds; so I think the > patch is still useful in the general case. > > The code for the changes is located in my MacRuby fork on github: > https://github.com/ferrous26/MacRuby/tree/libify-rubyc > > Mark Rada > mr...@marketcircle.com > > _______________________________________________ > MacRuby-devel mailing list > MacRuby-devel@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
