[Nitro] Re-doing parts of Nitro in C
rob at motionpath.com
Tue Feb 14 18:22:28 EST 2006
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.
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.
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.
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?
> 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
> Nitro-general mailing list
> Nitro-general at rubyforge.org
More information about the Nitro-general