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
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() for
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 only once
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
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 links
that
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)
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.
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 to
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
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,
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
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) memo-ized
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 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
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
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 links
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]
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,
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, try
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
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
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 how
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 a
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
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
25 matches
Mail list logo
