Catalyst vs Rails vs Django Cook off

I really don't want to start a bashing session, but I have
some  
concerns that those much more knowledgeable than me should
hopefully  
be able to clarify.

Recently, I saw this article via Catalyst Planet: http:// 
letsgetdugg.com/feed/view/Catalyst_vs_Rails_vs_Django_Cook_o
ff

Essentially, according to his test, which doesn't take into
account  
ORM performance, Rails & Django knock the socks of
Catalyst.

In victori's remarks, he calls for a change in Catalyst and
points to  
the other advantages to to this framework, mostly related to
ease of  
coding.  While the whole reason I came to Catalyst is
because I'm  
comfortable with Perl and don't want to learn Ruby, I'm
worried that  
my Catalyst application won't perform as well when/if my app
usage  
becomes very significant.  Should I be concerned?

Again, I'm not interesting in hearing about how
Rails/Ruby/Django/ 
Python sucks, but in facts about real performance of
Catalyst.


Many thanks,

Conan.

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

On 16/11/06, catalyst.20.chsgspamgourmet.com
<catalyst.20.chsgspamgourmet.com> wrote:
> I really don't want to start a bashing session, but I
have some
> concerns that those much more knowledgeable than me
should hopefully
> be able to clarify.
>
> Recently, I saw this article via Catalyst Planet:
http://
>
letsgetdugg.com/feed/view/Catalyst_vs_Rails_vs_Django_Cook_o
ff
>
> Essentially, according to his test, which doesn't take
into account
> ORM performance, Rails & Django knock the socks of
Catalyst.
>
> In victori's remarks, he calls for a change in Catalyst
and points to
> the other advantages to to this framework, mostly
related to ease of
> coding.  While the whole reason I came to Catalyst is
because I'm
> comfortable with Perl and don't want to learn Ruby, I'm
worried that
> my Catalyst application won't perform as well when/if
my app usage
> becomes very significant.  Should I be concerned?
>
> Again, I'm not interesting in hearing about how
Rails/Ruby/Django/
> Python sucks, but in facts about real performance of
Catalyst.

The first thing I noticed was that the content length of the
document
served by catalyst was longer than that served by rails.
He doesn't seem to have tried very hard to test "apples
for apples" (his words)

Also see the very good comment by "JayK" as to why
it's not a very
good real-world test at all.
http://letsgetdugg.com/view/Catalyst_vs_Rails_vs
_Django_Cook_off

I'm not saying Catalyst's performance couldn't be improved,
or that
it's not slower than Rails - just that a bad benchmark is
worthless.

Carl

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

catalyst.20.chsgspamgourmet.com wrote:
> In victori's remarks, he calls for a change in Catalyst
and points to 
> the other advantages to to this framework, mostly
related to ease of 
> coding.  While the whole reason I came to Catalyst is
because I'm 
> comfortable with Perl and don't want to learn Ruby, I'm
worried that my 
> Catalyst application won't perform as well when/if my
app usage becomes 
> very significant.  Should I be concerned?

No. Six apart certainly aren't, given http://vox.com/ is a Catalyst
app.

> Again, I'm not interesting in hearing about how
Rails/Ruby/Django/Python 
> sucks, but in facts about real performance of Catalyst.

The reality is that victori's benchmark successfully
measures only the base 
overhead of a request in an app with very few URL endpoints;
Catalyst's 
dispatch mechanism is optimised for speed of dispatch for
large applications 
and for allowing complex dispatch logic elegantly.

Besides which, I've never yet seen a production application
(and between 
Shadowcat's client portfolio I've seen not a small number
thereof) where the 
dispatch overhead was even statistically significant to the
overall 
performance - the bottleneck has always been either data
retrieval or template 
rendering.

-- 
      Matt S Trout       Offering custom development,
consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class
and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for
more information

+ Help us build a better perl ORM: http://dbix
-class.shadowcatsystems.co.uk/ +

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

On 11/16/06, Carl Franks <fireartistgmail.com> wrote:
> On 16/11/06, catalyst.20.chsgspamgourmet.com
> <catalyst.20.chsgspamgourmet.com> wrote:
> >
> > Essentially, according to his test, which doesn't
take into account
> > ORM performance, Rails & Django knock the
socks of Catalyst.

<snip>

> The first thing I noticed was that the content length
of the document
> served by catalyst was longer than that served by
rails.
> He doesn't seem to have tried very hard to test
"apples for apples" (his words)
>
> Also see the very good comment by "JayK" as
to why it's not a very
> good real-world test at all.
> http://letsgetdugg.com/view/Catalyst_vs_Rails_vs
_Django_Cook_off
>
> I'm not saying Catalyst's performance couldn't be
improved, or that
> it's not slower than Rails - just that a bad benchmark
is worthless.

I agree with all your points Carl. I have not been present
in teh IRC
for a few days to see any discussions related to this
thread.  I'm
sure some optimizations were discussed and some things will
be
implemented because of it.  So with the precondition that I
haven't
kept up with the state of affairs I'd like to thank victori
for
spending his time and effort to create _something_.  It's
more than
his naysayers have to done to show us how fast Catalyst is. 
I
respectfully suggest that those who criticize his work
should use
their energies to /improve/ his test rather than merely
dismissing it
as worthless.  Using his code as a base, couldn't one create
a test
that was more fair?  Then someone would have a test that
shows results
that are more 'real' and give potential users more
information with
which to make a decision.

Catalyst doesn't have to be the fastest in such a test. 
That's
probably never been the One True Goal of the core devs.  But
providing
people with information as to why Catalyst is good (or bad)
should be
high on the list.

-- 
Cory 'G' Watson
http://www.onemogin.com

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

On 16/11/06, Cory Watson <jheephatgmail.com> wrote:
> On 11/16/06, Carl Franks <fireartistgmail.com> wrote:
> > On 16/11/06, catalyst.20.chsgspamgourmet.com
> > <catalyst.20.chsgspamgourmet.com> wrote:
> > >
> > > Essentially, according to his test, which
doesn't take into account
> > > ORM performance, Rails & Django knock the
socks of Catalyst.
>
> <snip>
>
> > The first thing I noticed was that the content
length of the document
> > served by catalyst was longer than that served by
rails.
> > He doesn't seem to have tried very hard to test
"apples for apples" (his words)
> >
> > Also see the very good comment by "JayK"
as to why it's not a very
> > good real-world test at all.
> > http://letsgetdugg.com/view/Catalyst_vs_Rails_vs
_Django_Cook_off
> >
> > I'm not saying Catalyst's performance couldn't be
improved, or that
> > it's not slower than Rails - just that a bad
benchmark is worthless.
>
> I agree with all your points Carl. I have not been
present in teh IRC
> for a few days to see any discussions related to this
thread.  I'm

(me either)

> sure some optimizations were discussed and some things
will be
> implemented because of it.  So with the precondition
that I haven't
> kept up with the state of affairs I'd like to thank
victori for
> spending his time and effort to create _something_. 
It's more than
> his naysayers have to done to show us how fast Catalyst
is.  I
> respectfully suggest that those who criticize his work
should use
> their energies to /improve/ his test rather than merely
dismissing it
> as worthless.  Using his code as a base, couldn't one
create a test
> that was more fair?  Then someone would have a test
that shows results
> that are more 'real' and give potential users more
information with
> which to make a decision.

>From the off-list discussion I've already had, I know my
use of the
word 'worthless' will haunt me ;)

If a benchmark reveals something in the framework core which
could be
optimised, then that's great.
If it helps teach more effective idioms, or highlights
something that
shouldn't be used, then that's great.
But other than that, I don't think any application benchmark
will have
much worth other than for that specific application.

If I wanted to serve static pages (as the benchmark did), I
wouldn't
use a framework and then pipe them through TT.
The reason I use a framework, is because I want to write a
big
application with lots of pages, and have things like
sessions, ORM,
templates.

I don't see /how/ the benchmark can be improved. Once you
start
getting into something that complicated, all you're testing
is the way
1 person writes the application in perl compared to how they
write it
in ruby.
Someone else might use a different session storage-backend,
which
would have different results, and your 'fastest' framework
now isn't.

> Catalyst doesn't have to be the fastest in such a test.
 That's
> probably never been the One True Goal of the core devs.
 But providing
> people with information as to why Catalyst is good (or
bad) should be
> high on the list.

Carl

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

On 11/16/06, Matt S Trout <dbix-classtrout.me.uk> wrote:
> Besides which, I've never yet seen a production
application (and between
> Shadowcat's client portfolio I've seen not a small
number thereof) where the
> dispatch overhead was even statistically significant to
the overall
> performance - the bottleneck has always been either
data retrieval or template
> rendering.

This makes me wonder if these high traffic Catalyst sites
are using TT
or another templating solution. If they are using TT, it
should be
very helpful if someone published a sort of TT performance
guide. Or
at least a bulleted list with things not to do because I'm
probably
doing them all, given the current (lack of) speed from my
applications
without that much traffic. Any complex (or just plain big)
page will
take around 3-4 seconds to render with 90% of that time
being spent
with TT. The best work around was to use one of the caching
plugins
where I could, but users still have to experience crappy
load times
whenever something is updated on the database.

Thankfully, it's an internal system - so it's not *that*
critical.

-Nilson Santos F. Jr.

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

Carl Franks wrote:
> On 16/11/06, Cory Watson <jheephatgmail.com> wrote:
>> On 11/16/06, Carl Franks <fireartistgmail.com> wrote:
>> > On 16/11/06, catalyst.20.chsgspamgourmet.com
>> > <catalyst.20.chsgspamgourmet.com> wrote:
>> > >
>> > > Essentially, according to his test, which
doesn't take into account
>> > > ORM performance, Rails & Django knock
the socks of Catalyst.
>>
>> <snip>
>>
>> > The first thing I noticed was that the content
length of the document
>> > served by catalyst was longer than that served
by rails.
>> > He doesn't seem to have tried very hard to
test "apples for apples"
>> (his words)
>> >
>> > Also see the very good comment by
"JayK" as to why it's not a very
>> > good real-world test at all.
>> > http://letsgetdugg.com/view/Catalyst_vs_Rails_vs
_Django_Cook_off
>> >
>> > I'm not saying Catalyst's performance couldn't
be improved, or that
>> > it's not slower than Rails - just that a bad
benchmark is worthless.
>>
>> I agree with all your points Carl. I have not been
present in teh IRC
>> for a few days to see any discussions related to
this thread.  I'm
> 
> (me either)
> 
>> sure some optimizations were discussed and some
things will be
>> implemented because of it.  So with the
precondition that I haven't
>> kept up with the state of affairs I'd like to thank
victori for
>> spending his time and effort to create _something_.
 It's more than
>> his naysayers have to done to show us how fast
Catalyst is.  I
>> respectfully suggest that those who criticize his
work should use
>> their energies to /improve/ his test rather than
merely dismissing it
>> as worthless.  Using his code as a base, couldn't
one create a test
>> that was more fair?  Then someone would have a test
that shows results
>> that are more 'real' and give potential users more
information with
>> which to make a decision.
> 
>> From the off-list discussion I've already had, I
know my use of the
> word 'worthless' will haunt me ;)
> 
> If a benchmark reveals something in the framework core
which could be
> optimised, then that's great.
> If it helps teach more effective idioms, or highlights
something that
> shouldn't be used, then that's great.
> But other than that, I don't think any application
benchmark will have
> much worth other than for that specific application.
> 
> If I wanted to serve static pages (as the benchmark
did), I wouldn't
> use a framework and then pipe them through TT.
> The reason I use a framework, is because I want to
write a big
> application with lots of pages, and have things like
sessions, ORM,
> templates.
> 
> I don't see /how/ the benchmark can be improved. Once
you start
> getting into something that complicated, all you're
testing is the way
> 1 person writes the application in perl compared to how
they write it
> in ruby.
> Someone else might use a different session
storage-backend, which
> would have different results, and your 'fastest'
framework now isn't.
> 
>> Catalyst doesn't have to be the fastest in such a
test.  That's
>> probably never been the One True Goal of the core
devs.  But providing
>> people with information as to why Catalyst is good
(or bad) should be
>> high on the list.
> 
> Carl

/me puts on flame suit.

I agree overall. However...

I think the fact still remains that new end users will see
three
frameworks [all of which were destined for serving more than
static
pages] where 2 of them serve the static content fast, and
one doesn't
[Catalyst].

Regardless of whether the test is 'real world', and
regardless of
whether the frameworks 'were meant to serve more complicated
things',
Catalyst is slower in this instance. All things being
unequal, if I tell
my boss we have 3 frameworks to choose from, and one is
flexible, and
the others are fast, he's going to choose fast every
time...even knowing
the testing may be faulty. Yes, I know better. He probably
does too. But
that's how the world works.

I always fall on the side of the non majority it seems, and
this is
another example. [The list, not you specifically] Stop being
defensive
that the test is bogus. It's not. It shows that in one
circumstance,
Catalyst is sadly slow. Let's fix that. Explaining why the
test may be
invalid, or why it's bunk still won't change that fact that
in this
circumstance, it sucks.

/me removes suit and goes back to writing tests

-=Chris

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

On 16/11/06, Christopher H. Laco <clacochrislaco.com> wrote:
> Carl Franks wrote:
> > On 16/11/06, Cory Watson <jheephatgmail.com> wrote:
> >> On 11/16/06, Carl Franks <fireartistgmail.com> wrote:
> >> > On 16/11/06, catalyst.20.chsgspamgourmet.com
> >> > <catalyst.20.chsgspamgourmet.com> wrote:
> >> > >
> >> > > Essentially, according to his test,
which doesn't take into account
> >> > > ORM performance, Rails & Django
knock the socks of Catalyst.
> >>
> >> <snip>
> >>
> >> > The first thing I noticed was that the
content length of the document
> >> > served by catalyst was longer than that
served by rails.
> >> > He doesn't seem to have tried very hard
to test "apples for apples"
> >> (his words)
> >> >
> >> > Also see the very good comment by
"JayK" as to why it's not a very
> >> > good real-world test at all.
> >> > http://letsgetdugg.com/view/Catalyst_vs_Rails_vs
_Django_Cook_off
> >> >
> >> > I'm not saying Catalyst's performance
couldn't be improved, or that
> >> > it's not slower than Rails - just that a
bad benchmark is worthless.
> >>
> >> I agree with all your points Carl. I have not
been present in teh IRC
> >> for a few days to see any discussions related
to this thread.  I'm
> >
> > (me either)
> >
> >> sure some optimizations were discussed and
some things will be
> >> implemented because of it.  So with the
precondition that I haven't
> >> kept up with the state of affairs I'd like to
thank victori for
> >> spending his time and effort to create
_something_.  It's more than
> >> his naysayers have to done to show us how fast
Catalyst is.  I
> >> respectfully suggest that those who criticize
his work should use
> >> their energies to /improve/ his test rather
than merely dismissing it
> >> as worthless.  Using his code as a base,
couldn't one create a test
> >> that was more fair?  Then someone would have a
test that shows results
> >> that are more 'real' and give potential users
more information with
> >> which to make a decision.
> >
> >> From the off-list discussion I've already had,
I know my use of the
> > word 'worthless' will haunt me ;)
> >
> > If a benchmark reveals something in the framework
core which could be
> > optimised, then that's great.
> > If it helps teach more effective idioms, or
highlights something that
> > shouldn't be used, then that's great.
> > But other than that, I don't think any application
benchmark will have
> > much worth other than for that specific
application.
> >
> > If I wanted to serve static pages (as the
benchmark did), I wouldn't
> > use a framework and then pipe them through TT.
> > The reason I use a framework, is because I want to
write a big
> > application with lots of pages, and have things
like sessions, ORM,
> > templates.
> >
> > I don't see /how/ the benchmark can be improved.
Once you start
> > getting into something that complicated, all
you're testing is the way
> > 1 person writes the application in perl compared
to how they write it
> > in ruby.
> > Someone else might use a different session
storage-backend, which
> > would have different results, and your 'fastest'
framework now isn't.
> >
> >> Catalyst doesn't have to be the fastest in
such a test.  That's
> >> probably never been the One True Goal of the
core devs.  But providing
> >> people with information as to why Catalyst is
good (or bad) should be
> >> high on the list.
> >
> > Carl
>
> /me puts on flame suit.
>
> I agree overall. However...
>
> I think the fact still remains that new end users will
see three
> frameworks [all of which were destined for serving more
than static
> pages] where 2 of them serve the static content fast,
and one doesn't
> [Catalyst].
>
> Regardless of whether the test is 'real world', and
regardless of
> whether the frameworks 'were meant to serve more
complicated things',
> Catalyst is slower in this instance. All things being
unequal, if I tell
> my boss we have 3 frameworks to choose from, and one is
flexible, and
> the others are fast, he's going to choose fast every
time...even knowing
> the testing may be faulty. Yes, I know better. He
probably does too. But
> that's how the world works.
>
> I always fall on the side of the non majority it seems,
and this is
> another example. [The list, not you specifically] Stop
being defensive
> that the test is bogus. It's not.

I agree with everything up to here.

> It shows that in one circumstance,
> Catalyst is sadly slow. Let's fix that.

Matt has just pointed out that Cat's optimised for large
applications
with lots of paths, and for flexible programming.
Only fix it if that doesn't compromise this, which is more
important
than looking good in one flawed benchmark.

> Explaining why the test may be
> invalid, or why it's bunk still won't change that fact
that in this
> circumstance, it sucks.

Catalyst sucks because it doesn't come with a pony, so let's
hope the
next benchmark to hit the web doesn't benchmark against that
;)

> /me removes suit and goes back to writing tests

Um, shouldn't you leave the suit on until you've received
the replies?
I hope it wasn't needed anyway

Carl

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

Carl Franks wrote:
> On 16/11/06, Christopher H. Laco <clacochrislaco.com> wrote:
>> Carl Franks wrote:
>> > On 16/11/06, Cory Watson <jheephatgmail.com> wrote:
>> >> On 11/16/06, Carl Franks
<fireartistgmail.com> wrote:
>> >> > On 16/11/06, catalyst.20.chsgspamgourmet.com
>> >> > <catalyst.20.chsgspamgourmet.com> wrote:
>> >> > >
>> >> > > Essentially, according to his
test, which doesn't take into
>> account
>> >> > > ORM performance, Rails &
Django knock the socks of Catalyst.
>> >>
>> >> <snip>
>> >>
>> >> > The first thing I noticed was that
the content length of the
>> document
>> >> > served by catalyst was longer than
that served by rails.
>> >> > He doesn't seem to have tried very
hard to test "apples for apples"
>> >> (his words)
>> >> >
>> >> > Also see the very good comment by
"JayK" as to why it's not a very
>> >> > good real-world test at all.
>> >> > http://letsgetdugg.com/view/Catalyst_vs_Rails_vs
_Django_Cook_off
>> >> >
>> >> > I'm not saying Catalyst's performance
couldn't be improved, or that
>> >> > it's not slower than Rails - just
that a bad benchmark is worthless.
>> >>
>> >> I agree with all your points Carl. I have
not been present in teh IRC
>> >> for a few days to see any discussions
related to this thread.  I'm
>> >
>> > (me either)
>> >
>> >> sure some optimizations were discussed and
some things will be
>> >> implemented because of it.  So with the
precondition that I haven't
>> >> kept up with the state of affairs I'd like
to thank victori for
>> >> spending his time and effort to create
_something_.  It's more than
>> >> his naysayers have to done to show us how
fast Catalyst is.  I
>> >> respectfully suggest that those who
criticize his work should use
>> >> their energies to /improve/ his test
rather than merely dismissing it
>> >> as worthless.  Using his code as a base,
couldn't one create a test
>> >> that was more fair?  Then someone would
have a test that shows results
>> >> that are more 'real' and give potential
users more information with
>> >> which to make a decision.
>> >
>> >> From the off-list discussion I've already
had, I know my use of the
>> > word 'worthless' will haunt me ;)
>> >
>> > If a benchmark reveals something in the
framework core which could be
>> > optimised, then that's great.
>> > If it helps teach more effective idioms, or
highlights something that
>> > shouldn't be used, then that's great.
>> > But other than that, I don't think any
application benchmark will have
>> > much worth other than for that specific
application.
>> >
>> > If I wanted to serve static pages (as the
benchmark did), I wouldn't
>> > use a framework and then pipe them through TT.
>> > The reason I use a framework, is because I
want to write a big
>> > application with lots of pages, and have
things like sessions, ORM,
>> > templates.
>> >
>> > I don't see /how/ the benchmark can be
improved. Once you start
>> > getting into something that complicated, all
you're testing is the way
>> > 1 person writes the application in perl
compared to how they write it
>> > in ruby.
>> > Someone else might use a different session
storage-backend, which
>> > would have different results, and your
'fastest' framework now isn't.
>> >
>> >> Catalyst doesn't have to be the fastest in
such a test.  That's
>> >> probably never been the One True Goal of
the core devs.  But providing
>> >> people with information as to why Catalyst
is good (or bad) should be
>> >> high on the list.
>> >
>> > Carl
>>
>> /me puts on flame suit.
>>
>> I agree overall. However...
>>
>> I think the fact still remains that new end users
will see three
>> frameworks [all of which were destined for serving
more than static
>> pages] where 2 of them serve the static content
fast, and one doesn't
>> [Catalyst].
>>
>> Regardless of whether the test is 'real world', and
regardless of
>> whether the frameworks 'were meant to serve more
complicated things',
>> Catalyst is slower in this instance. All things
being unequal, if I tell
>> my boss we have 3 frameworks to choose from, and
one is flexible, and
>> the others are fast, he's going to choose fast
every time...even knowing
>> the testing may be faulty. Yes, I know better. He
probably does too. But
>> that's how the world works.
>>
>> I always fall on the side of the non majority it
seems, and this is
>> another example. [The list, not you specifically]
Stop being defensive
>> that the test is bogus. It's not.
> 
> I agree with everything up to here.
> 
>> It shows that in one circumstance,
>> Catalyst is sadly slow. Let's fix that.
> 
> Matt has just pointed out that Cat's optimised for
large applications
> with lots of paths, and for flexible programming.
> Only fix it if that doesn't compromise this, which is
more important
> than looking good in one flawed benchmark.

Agreed.

> 
>> Explaining why the test may be
>> invalid, or why it's bunk still won't change that
fact that in this
>> circumstance, it sucks.
> 
> Catalyst sucks because it doesn't come with a pony, so
let's hope the
> next benchmark to hit the web doesn't benchmark against
that ;)

Google has a pony, why can't I?
http://googleblog.blogspot.com/2006/10/yes-you-
can-have-pony.html

> 
>> /me removes suit and goes back to writing tests
> 
> Um, shouldn't you leave the suit on until you've
received the replies?

Nope. That's what filters to Trash are for. :-P

> I hope it wasn't needed anyway
> 
> Carl
> 
> _______________________________________________
> List: Catalystlists.rawmode.org
> Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
> Dev site: http://dev.catalyst.per
l.org/
> 
> 


_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/

On 11/16/06, Nilson Santos Figueiredo Junior <acid06gmail.com> wrote:
> On 11/16/06, Matt S Trout <dbix-classtrout.me.uk> wrote:
> > Besides which, I've never yet seen a production
application (and between
> > Shadowcat's client portfolio I've seen not a small
number thereof) where the
> > dispatch overhead was even statistically
significant to the overall
> > performance - the bottleneck has always been
either data retrieval or template
> > rendering.
>
> This makes me wonder if these high traffic Catalyst
sites are using TT
> or another templating solution. If they are using TT,
it should be
> very helpful if someone published a sort of TT
performance guide. Or
> at least a bulleted list with things not to do because
I'm probably
> doing them all, given the current (lack of) speed from
my applications
> without that much traffic. Any complex (or just plain
big) page will
> take around 3-4 seconds to render with 90% of that time
being spent
> with TT. The best work around was to use one of the
caching plugins
> where I could, but users still have to experience
crappy load times
> whenever something is updated on the database.
>
> Thankfully, it's an internal system - so it's not
*that* critical.
>

If template rendering speed might be a bottleneck for you,
you may
want to investigate ClearSilver.  I haven't tried it yet
myself, but
I've heard good things about its performance, and there's
already a
Cat View for it.  Its a bit different than other systems
though, in
that you explicitly define the structure of all of the data
going to
your template in an external file.

-- Brandon

_______________________________________________
List: Catalystlists.rawmode.org
Listinfo: ht
tp://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-
archive.com/catalystlists.rawmode.org/
Dev site: http://dev.catalyst.per
l.org/