On 2011-03-14, at 16:05, Laurent Sansonetti <lsansone...@apple.com> wrote:
> 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. > The splitting macrubyc was a low hanging fruit; macrubyc was almost split already, so few changes were introduced. I don't think I introduced much complexity, and in turn some clutter was separated from the initialization process: - calls to #die were replaced with calls to #raise - the option parser was moved out of the compiler class, now Compiler#initialize takes a hash of options and just unpacks it - most of the extra tool lookups (#locate) were moved to constants so they only have to be looked up once > I think a better strategy would be to optimize what's slow in macrubyc (such > as command-line options parsing), I don't think it's the command line parsing, I thinks it's the spawning of new MacRuby processes which will have to JIT the compiler logic over and over again for each file. But I guess a lot of that can be mitigated by compiling the compiler when it becomes possible. > and better include the compilation strategy into Xcode (if possible). > That does sound like a much better idea for macruby_deploy. However, I am rarely using Xcode to work with MacRuby, and there are other places where calling the compiler directly will have benefit, such as a rake task or during gem installation. Perhaps I am speaking for a minority in these two cases Sent from my iDevice > 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 _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
