On 09/10/02 11:56 -0700, Ryan Davis wrote: > > On Wednesday, October 9, 2002, at 09:03 AM, Brian Ingerson wrote: > > > So the first time dubble is called, it compiles/loads a single function > > shared object call main_dubble.so. The cool part is that the symbol > > table is > > then hacked to point to the C version instead of the Perl wrapper. > > That's > > about it. They do the whole thing in a very small amount of code. > > > > The obvious drawbacks are: > > - No typemapping > > - Must work the stack yourself > > - Happens at runtime > > I'm thinking about a way to do it at compile time, but I'm not sure how > it would go yet... probably something like: > > require 'inline' > class Blah > import Inline > compile_time_inline :methodname, <<-END > ....code.... > END > end > > but there are some minor things I need to flush out. > > I'm curious, why is this considered a drawback by you and/or the perl > inline community? I must ask, what is the benefit here that you guys > see over runtime compilation. On my machine (750Mhz P3 running > freebsd), it takes an average of .07 seconds to export, compare, and > compile over a normal load and run.
Hmm. Well it depends on your use cases. With CGI scripts, I recommend that people precache the objects by running the script once by hand. That way they don't need to give write access to caching directory for the CGI. With compile time building, this is easy. With run time builiding, you have to write extra code to make sure every Inline function code path is executed once. I'm not saying you're screwed, it just lays to rest any issues, present or future. Ask yourself the reverse, "What benefit am I providing to the user by making the code build at run time?". > > - Lots of little single function objects > > Again, why a drawback? On the ruby side, the load doesn't seem to cost > anything (that I can measure). Not from the throwaway script use case. But maybe from the distributed module use case. In Perl it would be weird for me to ship a module that had one .so per function. CPAN is a BIG precendent. I don't want to rock that whole boat. If Inline.pm did modules that way, I might have a hard time selling it to the p5p (core Perl maintainers). So even though Inline is groundbreaking on the UI side, I try to keep it "nothing to see here folks, move along" on the backend. But I don't have any good feeling for Ruby culture. I imagine it too be mucher younger, unjaded and maleable. Perhaps lots of little objects in the install tree is ok. But remember, Matz shamelessly copied Larry on all these architechural details. The ruby install trees practically mirror Perl's. So you might want to be careful yourself. If you distribute modules that actually *build at run time*, I think you'll hear objections. Inline.pm modules used to build at 'make test' time. At the time I thought no big deal, I get building for free and it's still before 'make install'. But sometimes people don't run tests. And it was just conceptually wrong. So I wrote Inline::MakeMaker as a wrapper around the real Make::Maker to create a Makefile which forced the compile at 'make' time. > > > - Probably for scripts only > > Why? How is the use case different for modules/classes vs scripts? As above, its just about what messes you are creating where and when. I'm not talking about modules that sit in the same directory as your personal script. I'm thinking about CRAN, the globally shared stuff. This is where you share your messes with the world. Just be careful. Cheers, Brian
