On Mar 9, 2007, at 10:04 AM, Robert 'phaylon' Sedlacek wrote:
Christopher H. Laco wrote:
Sure, it they're that different. The goal still stands, don't use
uri_for everywhere. Only use it when you really need it.
Jep. But this is not getting easier if you start to have captures
in your chai
On Friday 09 March 2007 12:51, Dave Rolsky wrote:
> On Fri, 9 Mar 2007, Andy Grundman wrote:
> > We've been discussing this a bit in #catalyst-dev. I think Memoize would
> > work, but it needs to be done carefully so it works with all our
> > different varieties of calling uri_for, and also with m
On Fri, 9 Mar 2007, Andy Grundman wrote:
We've been discussing this a bit in #catalyst-dev. I think Memoize would
work, but it needs to be done carefully so it works with all our different
varieties of calling uri_for, and also with multiple Catalyst apps running
under the same mod_perl insta
On Mar 9, 2007, at 12:41 PM, Bill Moseley wrote:
On Fri, Mar 09, 2007 at 11:34:14AM -0600, Dave Rolsky wrote:
On Fri, 9 Mar 2007, Bill Moseley wrote:
I just checked and on some pages I'm calling uri_for a few hundred
times. If that's a bottle neck then optimization would be most
welcome.
Perrin Harkins wrote:
On 3/9/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
I just checked and on some pages I'm calling uri_for a few hundred
times. If that's a bottle neck then optimization would be most
welcome.
I'm sure it depends on your usage, but for Jim Spath it was only about
4% of his
On Fri, Mar 09, 2007 at 11:34:14AM -0600, Dave Rolsky wrote:
> On Fri, 9 Mar 2007, Bill Moseley wrote:
>
> >I just checked and on some pages I'm calling uri_for a few hundred
> >times. If that's a bottle neck then optimization would be most
> >welcome.
>
> I did some hack-y testing of a (bad) me
Perrin Harkins wrote:
> On 3/9/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
>> I just checked and on some pages I'm calling uri_for a few hundred
>> times. If that's a bottle neck then optimization would be most
>> welcome.
>
> I'm sure it depends on your usage, but for Jim Spath it was only about
On Fri, 9 Mar 2007, Bill Moseley wrote:
I just checked and on some pages I'm calling uri_for a few hundred
times. If that's a bottle neck then optimization would be most
welcome.
I did some hack-y testing of a (bad) memo-ized version:
Benchmark: timing 1 iterations of memoized, not memoi
On 3/9/07, Bill Moseley <[EMAIL PROTECTED]> wrote:
I just checked and on some pages I'm calling uri_for a few hundred
times. If that's a bottle neck then optimization would be most
welcome.
I'm sure it depends on your usage, but for Jim Spath it was only about
4% of his time. It would help, b
On Fri, Mar 09, 2007 at 07:52:56AM +, Carl Franks wrote:
> This has been really bugging me, but I haven't had the time to look
> into it further.
>
> A URI object is a blessed string.
> A blessed uri-escaped string!
> So any method that changes a uri, or extracts info from it must be
> having
Robert 'phaylon' Sedlacek scribbled on 3/9/07 9:04 AM:
Christopher H. Laco wrote:
Sure, it they're that different. The goal still stands, don't use
uri_for everywhere. Only use it when you really need it.
Jep. But this is not getting easier if you start to have captures in
your chains. I'm
Christopher H. Laco wrote:
Sure, it they're that different. The goal still stands, don't use
uri_for everywhere. Only use it when you really need it.
Jep. But this is not getting easier if you start to have captures in
your chains. I'm still having high hopes to build something fast(er)
with
Robert 'phaylon' Sedlacek wrote:
> Christopher H. Laco wrote:
>
>> Even better, just don't use uri_for if you don't have to. Relative uris
>> are your friend. They still work. The web still functions without
>> uri_for. :-)
>>
>> If you are working on an index page, and you have create/edit/view l
Christopher H. Laco wrote:
Even better, just don't use uri_for if you don't have to. Relative uris
are your friend. They still work. The web still functions without
uri_for. :-)
If you are working on an index page, and you have create/edit/view links
that are relative to that page, just use htm
Nilson Santos Figueiredo Junior wrote:
> On 3/8/07, Jim Spath <[EMAIL PROTECTED]> wrote:
>> URI is next up at around 14% of time. Is there anything that can be
>> done about this one?
>
> Wherever is reasonably possible, instead of actually using calls to
> $c->uri_for() for every item, call it o
On 09/03/07, Nilson Santos Figueiredo Junior <[EMAIL PROTECTED]> wrote:
On 3/8/07, Jim Spath <[EMAIL PROTECTED]> wrote:
> URI is next up at around 14% of time. Is there anything that can be
> done about this one?
Wherever is reasonably possible, instead of actually using calls to
$c->uri_for()
On 3/8/07, Jim Spath <[EMAIL PROTECTED]> wrote:
URI is next up at around 14% of time. Is there anything that can be
done about this one?
Wherever is reasonably possible, instead of actually using calls to
$c->uri_for() for every item, call it only once and then build the
rest of the URI manual
On Thu, 8 Mar 2007, Jim Spath wrote:
The biggest problem seems to be localization at ~18%. I had been using
Catalyst::Plugin::I18N and calling Catalyst.localize() in our templates for
any string that required localization. Is there a better method for doing
localization, specifically with re
Perrin Harkins wrote:
On 3/8/07, Jim Spath <[EMAIL PROTECTED]> wrote:
On our development machine I ran myapp_server.pl through Devel::DProf,
hit it with a bunch of requests using ab, and got the following output:
Where's DBI? Did you sort this by wall time (-r flag)?
We are using Catalyst::
On 3/8/07, Jim Spath <[EMAIL PROTECTED]> wrote:
On our development machine I ran myapp_server.pl through Devel::DProf,
hit it with a bunch of requests using ab, and got the following output:
Where's DBI? Did you sort this by wall time (-r flag)?
Lastly, Template seems to be taking up around
Hi everyone,
We moved our Catalyst application to production servers yesterday and
seem to be getting lower than expected performance (around 9 req/s
between two load balanced servers).
On our development machine I ran myapp_server.pl through Devel::DProf,
hit it with a bunch of requests using a
I've previously posted about my performance issues regarding TT. At
the time, one of Matt's suggestions for improving performance was to
reduce the usage of uri_for() whenever possible.
I had some "list" pages where I'd need to display dozens of items and
link to each one of them and all my link
Hi,
On Oct 8, 2006, at 4:41 PM, Nilson Santos Figueiredo Junior wrote:
>
> I've never heard of ClearSilver before. I'll take a look at it.
> The thing is: I'm always suspicious of modules that aren't on the
> CPAN...
I'm not a fan of clearsilver, but it is on CPAN:
Catalyst::View::ClearSilver
Nilson Santos Figueiredo Junior ha scritto:
> I've never heard of ClearSilver before. I'll take a look at it.
> The thing is: I'm always suspicious of modules that aren't on the CPAN...
>
>
But it is on CPAN since august:
http://search.cpan.org/~jiro/Catalyst-View-ClearSilver-0.01
Bye,
Are you setup for caching the compiled templates? These should be set to
some sane value in TT options:
CACHE_SIZE
COMPILE_EXT
COMPILE_DIR
Also, you do not have EVAL_PERL set do you? I have seen huge performance
drops on setups that have that tagged.
Wade
[EMAIL PROTECTED] wrot
On 10/7/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
> Obviously you don't get all of TT's features. No EVAL, no MACRO, no
> BLOCK. I don't use any of that anyway. I write my code in perl, not in
> TT :)
Unfortunately, I use MACROs and BLOCKs extensively.
> Anyway, if you Need Something Now
Jonathan Rockway wrote:
>> Maybe it'd be nice if someone came up with a faster drop-in
>> replacement for TT... any volunteers? ;-)
>>
> I also noticed that TT is way too slow and am already working on it.
I think you'll have a very hard time doing it, unless you drop some of
the most popular
> Maybe it'd be nice if someone came up with a faster drop-in
> replacement for TT... any volunteers? ;-)
>
I also noticed that TT is way too slow and am already working on it.
Hopefully it will be finished this weekend.
http://trac.jrock.us/cpan_modules/browser/templates
Obviously you don't
Nilson Santos Figueiredo Junior wrote:
> Manually running and timing the queries as output when DBIC_TRACE=1.
>
> Switching from running a "$rs->next" loop inside TT to loading the
> objects inside the controller (through $rs->all). Then I tried using
> $rs->all inside the template and noticed the
On 10/7/06, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> Maybe this will help: http://www.modperlbook.org/html/ch09_05.html
Thanks, I'll try using Apache::DProf as suggested.
> How did you determine this?
Manually running and timing the queries as output when DBIC_TRACE=1.
Switching from running
Nilson Santos Figueiredo Junior wrote:
> Actually, next::method calls are somewhat expensive when you're using
> them for *everything* as it is on Catalyst / DBIC.
I don't think Catalyst uses Class::C3.
>> That will be mostly useless unless you add the -r flag. The reason is
>> that this profile
On 10/7/06, Matt S Trout <[EMAIL PROTECTED]> wrote:
> The Class::C3::* methods you're seeing are startup overhead only; unless
> you're messing with class hierarchies at run-time that's a one-off hit.
Right. But next::method calls also seem to weight in a "little bit".
But I really have no idea on
On 10/7/06, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> I haven't used DBIC, but I understand that the Class::C3 hit is mostly
> during startup. You don't want to profile that, since it doesn't affect
> the speed of your application. With mod_perl, you can skip that part by
> looking at the profi
Nilson Santos Figueiredo Junior wrote:
> Hi everyone,
>
> Recently I've been facing some performance issues in my Catalyst
> application and the situation worries me a little bit.
>
> The first optimization I tried was to start prefetching everything I
> could and it indeed improved the performan
Nilson Santos Figueiredo Junior wrote:
> I've got pages that take 3-4 seconds to render with a single user
> using the application while the database query takes something between
> 0.15-0.20s to complete.
How are you measuring those query times? The DBI profiler is a good
idea, if you haven't t
Hi everyone,
Recently I've been facing some performance issues in my Catalyst
application and the situation worries me a little bit.
The first optimization I tried was to start prefetching everything I
could and it indeed improved the performance quite a bit (by a factor
of 2 or so). But it still
On 14 Jul 2006, at 00:19, Michael Giambalvo wrote:
> I'd like to make an application where the client keeps a connection
> open to the server as a channel to receive events. Here are some
> examples of what I'm shooting for
>
> http://ajaxpatterns.org/HTTP_Streaming
> http://www.lightstreamer.co
I'd like to make an application where the client keeps a connection
open to the server as a channel to receive events. Here are some
examples of what I'm shooting for
http://ajaxpatterns.org/HTTP_Streaming
http://www.lightstreamer.com/
What I'm wondering is what would be the ideal catalyst setup
38 matches
Mail list logo
