[Nitro] Re-doing parts of Nitro in C

Bryan Soto bryan.a.soto at gmail.com
Wed Feb 15 16:23:52 EST 2006

On 2/14/06, rob <rob at motionpath.com> wrote:
> Sorry for the huge delay in replying to this...
> At the time I could not complete a run of nitro with profiler but
> have since realised this is probably due to the auto-reload thread
> hogging too much CPU when using set_trace_func (I've noticed this
> behavior when using our own custom tracer). I noticed the scaffold
> compilers use excessive CPU (one our larger projects they can often
> take over a minute to pre-compile at startup) and one of our very
> large Nitro projects hangs for a good 40 seconds on start-up on a 3
> ghz zeon with 2 gig of RAM even with this disabled so there are
> clearly some other areas that could be improved.

Useless speculation makes me think that's probably walking object space for
manageable classes and checks against the database for schema evolution
purposes. That's probably a big cost for you since, I recall, some of your
apps have 30+ tables?

Of course, the first rule of optimizing without hard numbers is, 'Whatever
you're thinking is wrong'. ;)

I suspect the PostgreSQL adapter also uses more CPU than it should
> since it's quite a nasty mess of patches to patches and could do with
> being re-done from scratch (maybe someday :)) I haven't looked too
> closely at the others.

They could all do with a rewrite, yes. :) Or at least some refactoring. A
lot of things can be pushed up to the superclass.

One idea I have had for improving template compile times is the
> compile could be cached, i.e the resulting code dumped to a file
> before evaluating it and the files updated as appropriate when the
> pertinent source files mtimes change.

Interesting thought. I wonder how much of a gain that would get you...

I will at some point get profiler running inside of that project (or
> make a different profiler...) and post you results.
> On 20 Jan 2006, at 11:22, George Moschovitis wrote:
> > This is on my todo list. Out of couriosity, wich parts have you
> > identified as processor intensive?
> >
> > -g.
> >
> > On 1/20/06, Rob Pitt <rob at motionpath.com> wrote:
> >> What are your positions on re-doing particularly processor or memory
> >> intensive parts of Nitro in C as ruby modules? Perhaps as an
> >> alternative, i.e. the pure ruby version would be used in case the end
> >> user cannot compile for some reason?
> >>
> >> _______________________________________________
> >> Nitro-general mailing list
> >> Nitro-general at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/nitro-general
> >>
> >
> >
> > --
> > http://www.gmosx.com
> > http://www.navel.gr
> > http://www.nitrohq.com
> >
> > _______________________________________________
> > Nitro-general mailing list
> > Nitro-general at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/nitro-general
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20060215/976a5431/attachment.html 

More information about the Nitro-general mailing list