Right.  The point was to show how much _lighter_ it was rather then
how much faster. :)  It's faster because it does less but does 99% of
what's needed for a lot of use cases.

Honestly, I wasn't thinking about their modes and all that when I did
my initial speed tests, so hopefully these new numbers will look more
normal.

--Jeremy

On Jan 6, 2008 12:13 PM, ara.t.howard <ara.t.howard / gmail.com> wrote:
>
> On Jan 6, 2008, at 9:24 AM, Jeremy McAnally wrote:
>
> > No I didn't run those in production, but that's mostly because Vintage
> > reloads templates every time (i.e., no caching and such like
> > production modes on both of those).  I didn't think about sessions, so
> > I should turn those off.  These numbers were for the same
> > functionality among all the frameworks.
>
> i can see you line of thinking, still, rails and merb both are
> loading a TON of more crap and doing a TON more tests if mode!
> =production, so it's probably worthwhile to either test those in
> production or implement caching - which is pretty easy (un-tested):
>
> class Template
>    Cache = Hash.new
>    Development = ENV['development']
>
>    if Development
>      def self.read path
>        IO.read(path)
>      end
>    else
>      def self.read path
>        Cache[path] ||= IO.read(path)
>      end
>    end
> end
>
> not that this would work for anything but testing - but that it does...
>
> >
> > I'm working on some better numbers using production modes, evented
> > Mongrels, Thin, and so on.  I'll post them here (hopefully) tonight
> > when I can get the data collected. :)
>
>
> cool.  the reason i asked the question is that after doing some
> careful benchmarks myself i've come to the conclusion that the only
> way to get more than a modest speedup out of a ruby web framework,
> when compared to rails, is to rework things like cgi parsing in C
> (which is done and released as a library) rather than tweak the ruby
> bits and framework code.  it's true that one could expect a speedup
> of 2x or something but, for me, i'd need to see a speedup of around
> and order of magnitude or something to make a switch worthwhile and
> my hunch is that - once the code for a 'real' app like sessions, db
> connection, etc are thrown in - all ruby frameworks will be very
> closely matched to rails, which has seen heavy optimization in many
> of it's billions of lines of code.  note that i'm really hoping to be
> proven wrong - but that's my gut feeling at the moment.  i'll follow
> vintage with great interest.
>
> kind regards.
>
> a @ http://codeforpeople.com/
> --
> share your knowledge.  it's a way to achieve immortality.
>
> h.h. the 14th dalai lama
>
>
>
>



-- 
http://www.jeremymcanally.com/

My books:
Ruby in Practice
http://www.manning.com/mcanally/

My free Ruby e-book
http://www.humblelittlerubybook.com/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/