Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Catalyst: Users

Alternatives to Catalyst ?

 

 

Catalyst users RSS feed   Index | Next | Previous | View Threaded


syber.rus at gmail

Apr 21, 2010, 9:30 AM

Post #1 of 72 (5152 views)
Permalink
Alternatives to Catalyst ?

This was the last shot for me at "dealing" with catalyst.
Catalyst is very perfomance-optimized system and it never stops me wondering

timethese(-1, {
sep => sub { $req->param('lang') },
all => sub { $req->params->{lang} },
par => sub { $req->parameters->{lang} },
low => sub { $req->{parameters}{lang} },
});

Benchmark: running all, low, par, sep for at least 1 CPU seconds...
all: 1 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @
74016.94/s (n=78643)
low: 1 wallclock secs ( 1.09 usr + 0.00 sys = 1.09 CPU) @
3816940.66/s (n=4144959)
par: 2 wallclock secs ( 1.12 usr + 0.00 sys = 1.12 CPU) @
75281.78/s (n=84692)
sep: 1 wallclock secs ( 1.02 usr + 0.00 sys = 1.02 CPU) @
24448.98/s (n=25022)


1) Getting all params 3x faster than only one
2) Getting $req->{parameters}{lang} 150x faster than $req->param('lang')

Guys, is Catalyst a senior system ?

I think that creator of Moose, and some similar shit is in cooperation
with hardware manufactorers :-)
The more CPU spent - the more hardware bought.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


syber.rus at gmail

Apr 21, 2010, 9:35 AM

Post #2 of 72 (5065 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Remembered one more thing.

DBIC's

$schema->resultset('RSNAME') is just a superstar!

Spending 800.000 CPU ticks at doing NOTHING. ingeniously


2010/4/21 Oleg Pronin <syber.rus [at] gmail>:
> This was the last shot for me at "dealing" with catalyst.
> Catalyst is very perfomance-optimized system and it never stops me wondering
>
> timethese(-1, {
> sep => sub { $req->param('lang') },
> all => sub { $req->params->{lang} },
> par => sub { $req->parameters->{lang} },
> low => sub { $req->{parameters}{lang} },
> });
>
> Benchmark: running all, low, par, sep for at least 1 CPU seconds...
> all: 1 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @
> 74016.94/s (n=78643)
> low: 1 wallclock secs ( 1.09 usr + 0.00 sys = 1.09 CPU) @
> 3816940.66/s (n=4144959)
> par: 2 wallclock secs ( 1.12 usr + 0.00 sys = 1.12 CPU) @
> 75281.78/s (n=84692)
> sep: 1 wallclock secs ( 1.02 usr + 0.00 sys = 1.02 CPU) @
> 24448.98/s (n=25022)
>
>
> 1) Getting all params 3x faster than only one
> 2) Getting $req->{parameters}{lang} 150x faster than $req->param('lang')
>
> Guys, is Catalyst a senior system ?
>
> I think that creator of Moose, and some similar shit is in cooperation
> with hardware manufactorers :-)
> The more CPU spent - the more hardware bought.
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


amesdaq at websense

Apr 21, 2010, 9:49 AM

Post #3 of 72 (5063 views)
Permalink
RE: Alternatives to Catalyst ? [In reply to]

I'm sure the developers are open to hearing your ideas for optimization and performance improvements.

Thanks,
------------------------------------------
Ali Mesdaq (CISSP, GIAC-GREM)
Sr. Security Researcher
Websense Security Labs
http://www.WebsenseSecurityLabs.com
------------------------------------------


-----Original Message-----
From: Oleg Pronin [mailto:syber.rus [at] gmail]
Sent: Wednesday, April 21, 2010 9:30 AM
To: The elegant MVC web framework
Subject: [Catalyst] Alternatives to Catalyst ?

This was the last shot for me at "dealing" with catalyst.
Catalyst is very perfomance-optimized system and it never stops me wondering

timethese(-1, {
sep => sub { $req->param('lang') },
all => sub { $req->params->{lang} },
par => sub { $req->parameters->{lang} },
low => sub { $req->{parameters}{lang} },
});

Benchmark: running all, low, par, sep for at least 1 CPU seconds...
all: 1 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @
74016.94/s (n=78643)
low: 1 wallclock secs ( 1.09 usr + 0.00 sys = 1.09 CPU) @
3816940.66/s (n=4144959)
par: 2 wallclock secs ( 1.12 usr + 0.00 sys = 1.12 CPU) @
75281.78/s (n=84692)
sep: 1 wallclock secs ( 1.02 usr + 0.00 sys = 1.02 CPU) @
24448.98/s (n=25022)


1) Getting all params 3x faster than only one
2) Getting $req->{parameters}{lang} 150x faster than $req->param('lang')

Guys, is Catalyst a senior system ?

I think that creator of Moose, and some similar shit is in cooperation
with hardware manufactorers :-)
The more CPU spent - the more hardware bought.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


Protected by Websense Hosted Email Security -- www.websense.com

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jshirley at gmail

Apr 21, 2010, 10:01 AM

Post #4 of 72 (5062 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Wed, Apr 21, 2010 at 9:30 AM, Oleg Pronin <syber.rus [at] gmail> wrote:
> This was the last shot for me at "dealing" with catalyst.
> Catalyst is very perfomance-optimized system and it never stops me wondering
>
> timethese(-1, {
> sep => sub { $req->param('lang') },
> all => sub { $req->params->{lang} },
> par => sub { $req->parameters->{lang} },
> low => sub { $req->{parameters}{lang} },
> });
>
> Benchmark: running all, low, par, sep for at least 1 CPU seconds...
> all: 1 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @
> 74016.94/s (n=78643)
> low: 1 wallclock secs ( 1.09 usr + 0.00 sys = 1.09 CPU) @
> 3816940.66/s (n=4144959)
> par: 2 wallclock secs ( 1.12 usr + 0.00 sys = 1.12 CPU) @
> 75281.78/s (n=84692)
> sep: 1 wallclock secs ( 1.02 usr + 0.00 sys = 1.02 CPU) @
> 24448.98/s (n=25022)
>
>
> 1) Getting all params 3x faster than only one
> 2) Getting $req->{parameters}{lang} 150x faster than $req->param('lang')
>
> Guys, is Catalyst a senior system ?
>
> I think that creator of Moose, and some similar shit is in cooperation
> with hardware manufactorers :-)
> The more CPU spent - the more hardware bought.
>


Maybe you should just go straight to C or assembly?


use Benchmark;

my $foo = { lang => 'en', silly => 'tests', are => 'silly' };

sub foos { return $foo; }
sub foo { return $foo->{$_[0]}; }

timethese(-1, {
sep => sub { foo('lang'); },
all => sub { foos()->{lang}; },
low => sub { $foo->{lang}; }
});

__END__
Benchmark: running all, low, sep for at least 1 CPU seconds...
all: 1 wallclock secs ( 1.11 usr + 0.00 sys = 1.11 CPU) @
2917341.44/s (n=3238249)
low: 0 wallclock secs ( 1.27 usr + 0.04 sys = 1.31 CPU) @
12930179.39/s (n=16938535)
sep: 1 wallclock secs ( 1.21 usr + 0.01 sys = 1.22 CPU) @
3223081.15/s (n=3932159)

Subroutines suck, lets all use hashrefs.

(PS, your 'all' and 'par' tests are identical, as params is simply an
alias to parameters).

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


larryl at emailplus

Apr 21, 2010, 10:27 AM

Post #5 of 72 (5055 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Wed, 21 Apr 2010 20:30 +0400, "Oleg Pronin" <syber.rus [at] gmail>
wrote:
>
> 1) Getting all params 3x faster than only one
> 2) Getting $req->{parameters}{lang} 150x faster than $req->param('lang')

What a surprise: accessing the hash directly is faster than calling a
function that accesses the hash. Plus, the docs state that
$req->param() is considered a legacy interface to provide CGI.pm
compatibility, and if you look at the source it's obvious it has to do
extra work to make it work like CGI.pm. If you don't need that, don't
use it.


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


nick at nickandperla

Apr 21, 2010, 10:44 AM

Post #6 of 72 (5057 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Wed, 21 Apr 2010 20:30:03 +0400
Oleg Pronin <syber.rus [at] gmail> wrote:

> Guys, is Catalyst a senior system ?
>
> I think that creator of Moose, and some similar shit is in cooperation
> with hardware manufactorers :-)
> The more CPU spent - the more hardware bought.

Did you want an alternative or were you just trolling? Have you
explored other frameworks that provide similar, comparable features?
Also, since you prefer hash access so much more, I hope I never get to
maintain your unconstrained, unvalidated code.

--

Nicholas Perez
XMPP/Email: nick [at] nickandperla
http://search.cpan.org/~nperez/
http://github.com/nperez

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


wbs at grepit

Apr 22, 2010, 10:52 AM

Post #7 of 72 (5026 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Apr 21, 2010, at 1:27 PM, "Larry Leszczynski"
<larryl [at] emailplus> wrote:

>
> On Wed, 21 Apr 2010 20:30 +0400, "Oleg Pronin" <syber.rus [at] gmail>
> wrote:
>>
>> 1) Getting all params 3x faster than only one
>> 2) Getting $req->{parameters}{lang} 150x faster than $req->param
>> ('lang')
>
> What a surprise: accessing the hash directly is faster than calling a
> function that accesses the hash. Plus, the docs state that
>

Exactly what I was thinking, does this really come as a surprise to
any perl dev? It seems on par with wondering why a tight loop that
recompiles RE performs slower than precompiled...

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


pagaltzis at gmx

Apr 22, 2010, 3:29 PM

Post #8 of 72 (5021 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

* Oleg Pronin <syber.rus [at] gmail> [2010-04-21 18:40]:
> Guys, is Catalyst a senior system ?
>
> I think that creator of Moose, and some similar shit is in
> cooperation with hardware manufactorers :-)
> The more CPU spent - the more hardware bought.

You should switch to PHP.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


webmaster at cosmicperl

Apr 22, 2010, 4:10 PM

Post #9 of 72 (5020 views)
Permalink
Re: Re: Alternatives to Catalyst ? [In reply to]

Aristotle Pagaltzis wrote:
> You should switch to PHP.
>

PHP is pronounced "poop", and there is far too much poop on the web already.


Lyle


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


webmaster at cosmicperl

Apr 22, 2010, 4:12 PM

Post #10 of 72 (5021 views)
Permalink
Re: Re: Alternatives to Catalyst ? [In reply to]

Aristotle Pagaltzis wrote:
> * Oleg Pronin <syber.rus [at] gmail> [2010-04-21 18:40]:
>
>> Guys, is Catalyst a senior system ?
>>
>> I think that creator of Moose, and some similar shit is in
>> cooperation with hardware manufactorers :-)
>> The more CPU spent - the more hardware bought.
>>
>
> You should switch to PHP.
>

Maybe help Perl 6 development with some performance tuning?


Lyle


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


toby.corkindale at strategicdata

Apr 22, 2010, 10:01 PM

Post #11 of 72 (5009 views)
Permalink
Re: Re: Alternatives to Catalyst ? [In reply to]

On 23/04/10 09:10, Lyle wrote:
> Aristotle Pagaltzis wrote:
>> You should switch to PHP.
>
> PHP is pronounced "poop", and there is far too much poop on the web
> already.

There's also too much noise and not enough signal on the mailing list.

Can we all try and resist cheap shots, name-calling, me-too's and other
childish behaviour on here?

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


tamas at eisenberger

Apr 23, 2010, 2:15 AM

Post #12 of 72 (4996 views)
Permalink
Re: Re: Alternatives to Catalyst ? [In reply to]

Yeah :) Absolutely agree :DDDDD
--
Eisenberger Tamás <tamas [at] eisenberger>


On Fri, 2010-04-23 at 00:29 +0200, Aristotle Pagaltzis wrote:
> * Oleg Pronin <syber.rus [at] gmail> [2010-04-21 18:40]:
> > Guys, is Catalyst a senior system ?
> >
> > I think that creator of Moose, and some similar shit is in
> > cooperation with hardware manufactorers :-)
> > The more CPU spent - the more hardware bought.
>
> You should switch to PHP.
>
> Regards,
Attachments: smime.p7s (4.61 KB)


syber.rus at gmail

Apr 23, 2010, 4:36 AM

Post #13 of 72 (4995 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Can you hear the difference between 3mln/s and 24k/s ?

I do not say that using hashes are good. But i'm sure that developers
MUST NOT use super-slow frameworks like MooseXXXX-shit (which tries to
emulate perl6 on perl5: what for???) only to get "good maintened
code". That's the own problems of developers how do they organize
internals. Why users of Catalyst must suffer from that ? Or you wanna
tell that "good maintened code" must have a price of >100x slow down
??? that an absurdity can't you see it?

It is possible to get good code (with MIXINS, C3, etc) without such a
great losses. If you see that something slows down application more
than 2x why do you use it? kick it off ! Benchmark.pm is your friend!

Finnaly, you are creating framework for other people and the main
thing is how it looks outside, not inside.

Sorry for my "hard" post, i'm just a little nervious :(

2010/4/21 J. Shirley <jshirley [at] gmail>:
> On Wed, Apr 21, 2010 at 9:30 AM, Oleg Pronin <syber.rus [at] gmail> wrote:
>> This was the last shot for me at "dealing" with catalyst.
>> Catalyst is very perfomance-optimized system and it never stops me wondering
>>
>> timethese(-1, {
>> sep => sub { $req->param('lang') },
>> all => sub { $req->params->{lang} },
>> par => sub { $req->parameters->{lang} },
>> low => sub { $req->{parameters}{lang} },
>> });
>>
>> Benchmark: running all, low, par, sep for at least 1 CPU seconds...
>> all: 1 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @
>> 74016.94/s (n=78643)
>> low: 1 wallclock secs ( 1.09 usr + 0.00 sys = 1.09 CPU) @
>> 3816940.66/s (n=4144959)
>> par: 2 wallclock secs ( 1.12 usr + 0.00 sys = 1.12 CPU) @
>> 75281.78/s (n=84692)
>> sep: 1 wallclock secs ( 1.02 usr + 0.00 sys = 1.02 CPU) @
>> 24448.98/s (n=25022)
>>
>>
>> 1) Getting all params 3x faster than only one
>> 2) Getting $req->{parameters}{lang} 150x faster than $req->param('lang')
>>
>> Guys, is Catalyst a senior system ?
>>
>> I think that creator of Moose, and some similar shit is in cooperation
>> with hardware manufactorers :-)
>> The more CPU spent - the more hardware bought.
>>
>
>
> Maybe you should just go straight to C or assembly?
>
>
> use Benchmark;
>
> my $foo = { lang => 'en', silly => 'tests', are => 'silly' };
>
> sub foos { return $foo; }
> sub foo { return $foo->{$_[0]}; }
>
> timethese(-1, {
> sep => sub { foo('lang'); },
> all => sub { foos()->{lang}; },
> low => sub { $foo->{lang}; }
> });
>
> __END__
> Benchmark: running all, low, sep for at least 1 CPU seconds...
> all: 1 wallclock secs ( 1.11 usr + 0.00 sys = 1.11 CPU) @
> 2917341.44/s (n=3238249)
> low: 0 wallclock secs ( 1.27 usr + 0.04 sys = 1.31 CPU) @
> 12930179.39/s (n=16938535)
> sep: 1 wallclock secs ( 1.21 usr + 0.01 sys = 1.22 CPU) @
> 3223081.15/s (n=3932159)
>
> Subroutines suck, lets all use hashrefs.
>
> (PS, your 'all' and 'par' tests are identical, as params is simply an
> alias to parameters).
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


zzbbyy at gmail

Apr 23, 2010, 5:08 AM

Post #14 of 72 (5000 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Fri, Apr 23, 2010 at 12:36 PM, Oleg Pronin <syber.rus [at] gmail> wrote:
> Can you hear the difference between 3mln/s and 24k/s ?
>
> I do not say that using hashes are good. But i'm sure that developers
> MUST NOT use super-slow frameworks like MooseXXXX-shit (which tries to
> emulate perl6 on perl5:   what for???) only to get "good maintened
> code". That's the own problems of developers how do they organize
> internals. Why users of Catalyst must suffer from that ?  Or you wanna
> tell that "good maintened code" must have a price of >100x slow down
> ??? that an absurdity can't you see it?

Well - this is not that absurd as you seem to think - the meaning of
that "100x slow down" depends much on where it happens. If it
happens in a tight loop - then it can be harmful - if it happens on
some one-off operation then it mostly does not really matter. It is
not that using Moose slows your application 100 times - it can slow
some parts of it - but how that relates to the overall performance -
this depends on many things. I think that most of Catalyst users
found that it's port to the Moose framework did not slow their
applications much - but there sure there will be some cases that this
change was introducing some problems. Unfortunately it's always about
tradeoffs. But if you have a real-life example where the port caused
a 100 times slow down - then I am sure the developers here would like
to hear about the details.

Cheers,
Zbigniew
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jshirley at gmail

Apr 23, 2010, 5:33 AM

Post #15 of 72 (4999 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Fri, Apr 23, 2010 at 4:36 AM, Oleg Pronin <syber.rus [at] gmail> wrote:
> Can you hear the difference between 3mln/s and 24k/s ?
>
> I do not say that using hashes are good. But i'm sure that developers
> MUST NOT use super-slow frameworks like MooseXXXX-shit (which tries to
> emulate perl6 on perl5: what for???) only to get "good maintened
> code". That's the own problems of developers how do they organize
> internals. Why users of Catalyst must suffer from that ? Or you wanna
> tell that "good maintened code" must have a price of >100x slow down
> ??? that an absurdity can't you see it?
>
> It is possible to get good code (with MIXINS, C3, etc) without such a
> great losses. If you see that something slows down application more
> than 2x why do you use it? kick it off ! Benchmark.pm is your friend!
>
> Finnaly, you are creating framework for other people and the main
> thing is how it looks outside, not inside.
>
> Sorry for my "hard" post, i'm just a little nervious :(
>


Look, you may be nervous but it doesn't give you a right to be stupid
in public. That's exactly what you are being.

Did you see my benchmark post? It shows the *exact* same pattern by
simply wrapping a sub around a hash lookup. This is called
programming. You do things, it makes the CPU work. Done.

You have provided absolutely no useful Benchmarking, which would be an
entire request lifecycle against your idea of what a perfect request
would be.

What's your concern? That your site won't be fast enough? That's
bogus, because you could just ask, "Hey, who is running high profile,
high demand sites on Catalyst and what are your performance numbers?"
Then you wouldn't be acting like an asshole, and people would help you
out.

It's obvious you are struggling to understand a subject that you
aren't familiar with (performance optimization) and are lashing out at
the obvious things you can find ("A hash ref is faster than a sub,
lets never use a sub!"). Don't.

Spend some time properly benchmarking *your* application and see what
you can do to improve the throughput. Ask *specific* questions on
*specific* benchmarks.

Right now you are hand waving and making yourself look like a complete
idiot. You probably don't want to look like an idiot, so try taking
my advice.

-J

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


edencardim at gmail

Apr 23, 2010, 5:36 AM

Post #16 of 72 (5000 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Fri, Apr 23, 2010 at 8:36 AM, Oleg Pronin <syber.rus [at] gmail> wrote:
> Can you hear the difference between 3mln/s and 24k/s ?
> I do not say that using hashes are good. But i'm sure that developers
> MUST NOT use super-slow frameworks like MooseXXXX-shit (which tries to
> emulate perl6 on perl5: what for???) only to get "good maintened
> code". That's the own problems of developers how do they organize
> internals. Why users of Catalyst must suffer from that ?

You have the choice of using another framework, you also have the
choice of using a prior version of Catalyst that doesn't have Moose in
it, and you also have the choice of forking Catalyst and trying to
come up with something better. Good luck.

> Or you wanna
> tell that "good maintened code" must have a price of >100x slow down
> ??? that an absurdity can't you see it?
> It is possible to get good code (with MIXINS, C3, etc) without such a
> great losses. If you see that something slows down application more
> than 2x why do you use it? kick it off ! Benchmark.pm is your friend!

Your benchmark is flawed by definition, read what the other messages
in the topic say, putting a subroutine call in front of an access to a
hash key is going to raise execution time in any language or
framework.
High-level code is slower than low-level code, get used to it. If
execution slows down by 2x and speeds up development by 4x, it's
probably worth using, this is a very basic topic at software
engineering school, go educate yourself.

> Finnaly, you are creating framework for other people and the main
> thing is how it looks outside, not inside.

Yes, frameworks are supposed to encapsulate complexity. Again, a basic
topic in software engineering school.

> Sorry for my "hard" post, i'm just a little nervious :(

If you're nervous, see a shrink, trolling won't help you or anyone else.

--
Eden Cardim Need help with your Catalyst or DBIx::Class project?
Code Monkey http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://blog.edencardim.com/ http://www.shadowcat.co.uk/servers/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


syber.rus at gmail

Apr 23, 2010, 5:52 AM

Post #17 of 72 (4999 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Perfomance optimization are unavailable for you because only people
like you write such mega slow fuckin code. goodbye

2010/4/23 J. Shirley <jshirley [at] gmail>:
> On Fri, Apr 23, 2010 at 4:36 AM, Oleg Pronin <syber.rus [at] gmail> wrote:
>> Can you hear the difference between 3mln/s and 24k/s ?
>>
>> I do not say that using hashes are good. But i'm sure that developers
>> MUST NOT use super-slow frameworks like MooseXXXX-shit (which tries to
>> emulate perl6 on perl5: what for???) only to get "good maintened
>> code". That's the own problems of developers how do they organize
>> internals. Why users of Catalyst must suffer from that ? Or you wanna
>> tell that "good maintened code" must have a price of >100x slow down
>> ??? that an absurdity can't you see it?
>>
>> It is possible to get good code (with MIXINS, C3, etc) without such a
>> great losses. If you see that something slows down application more
>> than 2x why do you use it? kick it off ! Benchmark.pm is your friend!
>>
>> Finnaly, you are creating framework for other people and the main
>> thing is how it looks outside, not inside.
>>
>> Sorry for my "hard" post, i'm just a little nervious :(
>>
>
>
> Look, you may be nervous but it doesn't give you a right to be stupid
> in public. That's exactly what you are being.
>
> Did you see my benchmark post? It shows the *exact* same pattern by
> simply wrapping a sub around a hash lookup. This is called
> programming. You do things, it makes the CPU work. Done.
>
> You have provided absolutely no useful Benchmarking, which would be an
> entire request lifecycle against your idea of what a perfect request
> would be.
>
> What's your concern? That your site won't be fast enough? That's
> bogus, because you could just ask, "Hey, who is running high profile,
> high demand sites on Catalyst and what are your performance numbers?"
> Then you wouldn't be acting like an asshole, and people would help you
> out.
>
> It's obvious you are struggling to understand a subject that you
> aren't familiar with (performance optimization) and are lashing out at
> the obvious things you can find ("A hash ref is faster than a sub,
> lets never use a sub!"). Don't.
>
> Spend some time properly benchmarking *your* application and see what
> you can do to improve the throughput. Ask *specific* questions on
> *specific* benchmarks.
>
> Right now you are hand waving and making yourself look like a complete
> idiot. You probably don't want to look like an idiot, so try taking
> my advice.
>
> -J
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


mapeck65 at gmail

Apr 23, 2010, 6:51 AM

Post #18 of 72 (4984 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Fri, Apr 23, 2010 at 8:52 AM, Oleg Pronin <syber.rus [at] gmail> wrote:

> Perfomance optimization are unavailable for you because only people
> like you write such mega slow fuckin code. goodbye
>
> I have been lurking for quite some time, gleaning an incredible amount of
wisdom from experienced developers, willing to offer help to anyone who
asks. I truly pity Oleg for not listening to the truth given. It is
obvious that the specific benchmark tests he referenced were in no way
related to Catalyst. True, internally Moose or Catalyst may use hash
references predicated by a sub call, but that does not mean that /his/
problem, which he failed to define, was caused by them.

I hope he finds what he's looking for...in other words, I'm glad to see him
go. I was getting tired of his rants. Kudos to you all for handling him as
tactfully as you did, and again thank you for all the help you generously
provide to those willing to listen.


nazgul at somewhere

Apr 23, 2010, 8:51 AM

Post #19 of 72 (4978 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Apr 23, 2010, at 7:36 AM, Oleg Pronin wrote:

> Sorry for my "hard" post, i'm just a little nervious :(

No argument there. I dearly wish the effort that had gone into Perl6 had gone into a Perl5 IDE and web framework with a single "best in class" set of options (with docs) to bring a new, non-perl, programmer up to a working web site the same way it's possible with Ruby. Elegance isn't worth a damn if nobody is using it.

Kee Hinckley
Owner, Somewhere LLC. Somewhere: http://www.somewhere.com/ TechnoSocial: http://xrl.us/bh35i




_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


philip.g.potter at gmail

Apr 23, 2010, 9:11 AM

Post #20 of 72 (4981 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On 23 April 2010 16:51, Kee Hinckley <nazgul [at] somewhere> wrote:
> On Apr 23, 2010, at 7:36 AM, Oleg Pronin wrote:
>
>> Sorry for my "hard" post, i'm just a little nervious :(
>
> No argument there. I dearly wish the effort that had gone into Perl6 had gone into a Perl5 IDE and web framework
with a single "best in class" set of options (with docs) to bring a
new, non-perl, programmer up to a working web site the same way it's
possible with Ruby. Elegance isn't worth a damn if nobody is using it.

You're free to put that effort into Padre, the Perl IDE, or Catalyst,
or Dancer, until it suits your requirements.

In open source, what gets done is defined by those who do it.

Phil

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


randall.munden at gmail

Apr 23, 2010, 9:22 AM

Post #21 of 72 (4984 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Fri, Apr 23, 2010 at 11:11 AM, Philip Potter
<philip.g.potter [at] gmail> wrote:
.
.
.
> In open source, what gets done is defined by those who do it.
>
> Phil

Hear, hear.

--rjm--
-- Knowing is not enough; we must apply. Willing is not enough; we must do.

http://www.librarything.com/profile/blather
http://blather.smugmug.com/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


lars at balker

Apr 23, 2010, 9:58 AM

Post #22 of 72 (4972 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Fri, Apr 23, 2010 at 5:51 PM, Kee Hinckley <nazgul [at] somewhere> wrote:
> No argument there. I dearly wish the effort that had gone into Perl6 had gone into [blah blah].

You're subscribing to the fallacy that volunteer time is a resource
you can allocate as you see fit. That's not how it works.

chromatic has written at length about this subject, so I'm not going
to delve further into it.
--
Lars Balker Rasmussen Consult::Perl

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


webmaster at cosmicperl

Apr 23, 2010, 10:27 AM

Post #23 of 72 (4973 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Kee Hinckley wrote:
> No argument there. I dearly wish the effort that had gone into Perl6 had gone into a Perl5 IDE and web framework with a single "best in class" set of options (with docs) to bring a new, non-perl, programmer up to a working web site the same way it's possible with Ruby. Elegance isn't worth a damn if nobody is using it.
>

Perl 6 was/is the right thing to do. We can't keep bolting modern things
onto Perl 5, it just causes more issues like the performance things
mentioned in the start of this thread.
I wish a lot of this "modern perl 5" effort had gone towards Perl 6...
But like Lars pointed out, that's not how it works with volunteer time.

I'm sure Perl 6 ports of Cat and Padre will follow it's release.


Lyle

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jshirley at gmail

Apr 23, 2010, 10:35 AM

Post #24 of 72 (4975 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Fri, Apr 23, 2010 at 10:27 AM, Lyle <webmaster [at] cosmicperl> wrote:
> Kee Hinckley wrote:
>>
>> No argument there. I dearly wish the effort that had gone into Perl6 had
>> gone into a Perl5 IDE and web framework with a single "best in class" set of
>> options (with docs) to bring a new, non-perl, programmer up to a working web
>> site the same way it's possible with Ruby. Elegance isn't worth a damn if
>> nobody is using it.
>>
>
> Perl 6 was/is the right thing to do. We can't keep bolting modern things
> onto Perl 5, it just causes more issues like the performance things
> mentioned in the start of this thread.
> I wish a lot of this "modern perl 5" effort had gone towards Perl 6... But
> like Lars pointed out, that's not how it works with volunteer time.
>
> I'm sure Perl 6 ports of Cat and Padre will follow it's release.
>

Factually, this isn't correct (and is in fact the opposite). A lot of
the perl6 work that has been brought into perl5 is available in
5.10.0+ as new features, which are *increasing* the speed of
Moose/Class::MOP.

Moose and Class::MOP are not Perl6. It brings some Perl6 features
into Perl5, but that's not what it is for.

Perl 5 runs now. It runs many, many businesses. Perl 5.10 is a
backwards-compatible release that speeds up many improvements brought
about by using Class::MOP and Moose, as well as added a wealth of new
features.

They are separate. They are not the same.

To compare the efforts between the two, on a technical level, is like
saying that you wish the momentum that Ruby had was instead placed in
Perl6.

Different things are different, just because there were Perl 5 hackers
that moved on to work on Perl6 doesn't change that they are very
different. The Perl6 hackers are language guys, loving to work on
languages. The Perl 5 people are solving real world problems that you
see on the CPAN.

Both are absolutely necessary and very valuable to the community, but
to confuse Perl6 as being a resource drain on Perl 5 (or in reverse)
is misguided.

They're both sharing work, and Perl 5 is improving from many angles.

This thread has sure gone crazy...

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jmac at jmac

Apr 23, 2010, 11:12 AM

Post #25 of 72 (4975 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Fri, Apr 23, 2010 at 1:35 PM, J. Shirley <jshirley [at] gmail> wrote:
>
> They're both sharing work, and Perl 5 is improving from many angles.

Something I've been fond of saying lately, especially to those outside
this community, is that Perl6 is the skunkworks lab for Perl. (AKA
"Perl5", but, practically: Perl.) The Perl6 engineers keep inventing
crazy things, and some are so crazy that they're crazy-awesome; these
are the ones that get adopted into Perl, whether as core features or
community-adopted modules like Moose and Class::MOP.

I've long since stopped thinking of Perl6 as a new programming
language that I should wait for; its name, rather, is merely an
artifact of its origins. It has, in the years since its inception,
settled into the role of a test lab and proving grounds for creative
new features for my favorite programming language, and that is a
beautiful thing.

> This thread has sure gone crazy...

It's ending up in a more interesting place than it started, at least.

--
Jason McIntosh

http://jmac.org • jmac [at] jmac • @JmacDotOrg

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


nazgul at somewhere

Apr 23, 2010, 12:20 PM

Post #26 of 72 (4510 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Apr 23, 2010, at 12:58 PM, Lars Balker Rasmussen wrote:

> On Fri, Apr 23, 2010 at 5:51 PM, Kee Hinckley <nazgul [at] somewhere> wrote:
>> No argument there. I dearly wish the effort that had gone into Perl6 had gone into [blah blah].
>
> You're subscribing to the fallacy that volunteer time is a resource
> you can allocate as you see fit. That's not how it works.

I'm very aware of that, having contributed to various projects for 20+ years. If I could allocate volunteer time as I wished, I'd allocate *my* time towards it. LOL. It's a wish, that's all.
_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


benvanstaveren at gmail

Apr 23, 2010, 12:21 PM

Post #27 of 72 (4514 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

> I do not say that using hashes are good. But i'm sure that developers
> MUST NOT use super-slow frameworks like MooseXXXX-shit (which tries to
> emulate perl6 on perl5: what for???) only to get "good maintened
> code". That's the own problems of developers how do they organize
> internals. Why users of Catalyst must suffer from that ? Or you wanna
> tell that "good maintened code" must have a price of >100x slow down
> ??? that an absurdity can't you see it?
>
Cost of hardware to compensate the slowdown is generally speaking much
less than the cost of programmers to maintain crappy spaghetti code.

Yes, Moose has overhead, quite significant at that during startup, but
on the whole, those few CPU cycles aren't something you will be bothered
by. Most servers these days have an abundance of them, you see. When you
start hitting 100% CPU, you can most likely get better gains from
streamlining the code you have as opposed to switching to the 1995 way
of doing things.

> It is possible to get good code (with MIXINS, C3, etc) without such a
> great losses. If you see that something slows down application more
> than 2x why do you use it? kick it off ! Benchmark.pm is your friend!
>
>
Lies, damn lies, and statistics. Benchmarking is nice, but benchmarks
also tend to cloud issues. Yes, direct hash accesses are faster than
going through an accessor which does validation. Simple matter of the
latter needing more ops to do what it does.
> Finnaly, you are creating framework for other people and the main
> thing is how it looks outside, not inside.
>
>
Yes, at the same time, you're advocating that Catalyst should be coded
according to your wishes and desires, in order to be faster. That's
great, what about those of us who have to deal with maintaining large
Catalyst applications, where we care a bit more about the ease of
maintenance than the cost of the hardware needed to run it.

On that note, by the time you have an app big enough to need more oomph,
you're probably at a point in time where you can afford to pay this
cost. Your average garden variety home-brew app doesn't need major
horsepower, but it needs to be easily maintained.

> Sorry for my "hard" post, i'm just a little nervious :(
>
Well, no hard feelings, but do try to back up statements like 'Moose
shit' with facts ;)

--
Ben van Staveren
phone: +62 81 70777529
email: benvanstaveren [at] gmail


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jester at panix

Apr 24, 2010, 5:53 PM

Post #28 of 72 (4463 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Fri, Apr 23, 2010 at 04:52:42PM +0400, Oleg Pronin wrote:
> Perfomance optimization are unavailable for you because only people
> like you write such mega slow fuckin code. goodbye

Goodbye.

*plonk*

Jesse Sheidlower

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


paikkos at googlemail

Apr 26, 2010, 2:36 AM

Post #29 of 72 (4381 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On 21 April 2010 18:01, J. Shirley <jshirley [at] gmail> wrote:

>
> __END__
> Benchmark: running all, low, sep for at least 1 CPU seconds...
> all: 1 wallclock secs ( 1.11 usr + 0.00 sys = 1.11 CPU) @
> 2917341.44/s (n=3238249)
> low: 0 wallclock secs ( 1.27 usr + 0.04 sys = 1.31 CPU) @
> 12930179.39/s (n=16938535)
> sep: 1 wallclock secs ( 1.21 usr + 0.01 sys = 1.22 CPU) @
> 3223081.15/s (n=3932159)
>
> Subroutines suck, lets all use hashrefs.


Now that it's quietened down, I can ask a question. Does this I mean
it's preferable to use

$c->req->{parameters}->{foo}

rather than

$c->req->param('foo')

Obviously I'd rather use the faster method but if I'm breaking the
encapsulation in some ways that's going to bite me later, I'd steer
clear.
Dp.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


tobias.kremer at gmail

Apr 26, 2010, 2:39 AM

Post #30 of 72 (4380 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

> Now that it's quietened down, I can ask a question. Does this I mean> it's preferable to use
> $c->req->{parameters}->{foo}
> rather than
> $c->req->param('foo')

AFAIK, the preferred way is:

$c->req->params->{ 'foo' }

--Toby

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


avarab at gmail

Apr 26, 2010, 2:57 AM

Post #31 of 72 (4379 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Mon, Apr 26, 2010 at 09:36, Dermot <paikkos [at] googlemail> wrote:
> On 21 April 2010 18:01, J. Shirley <jshirley [at] gmail> wrote:
>> __END__
>> Benchmark: running all, low, sep for at least 1 CPU seconds...
>>       all:  1 wallclock secs ( 1.11 usr +  0.00 sys =  1.11 CPU) @
>> 2917341.44/s (n=3238249)
>>       low:  0 wallclock secs ( 1.27 usr +  0.04 sys =  1.31 CPU) @
>> 12930179.39/s (n=16938535)
>>       sep:  1 wallclock secs ( 1.21 usr +  0.01 sys =  1.22 CPU) @
>> 3223081.15/s (n=3932159)
>>
>> Subroutines suck, lets all use hashrefs.
>
> Now that it's quietened down, I can ask a question. Does this I mean
> it's preferable to use
>
> $c->req->{parameters}->{foo}
>
> rather than
>
> $c->req->param('foo')
>
> Obviously I'd rather use the faster method but if I'm breaking the
> encapsulation in some ways that's going to bite me later, I'd steer
> clear.

"Obviously".

Unless you're doing method calls in a tight loop somewhere in your
code you *shouldn't care about this*. Now I've written code that
actually *did* suffer from method call overhead but since you're just
casually asking it's very unlikely that you're doing the same.

Don't sprinkle premature optimizations around your codebase just
because someone produced a benchmark showing one is faster than the
other. You should be doing *profiling* of your entire program, not
micro-optimizing something that's likely 0.0001% of its total runtime.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


orasnita at gmail

Apr 26, 2010, 3:13 AM

Post #32 of 72 (4378 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

From: "Ævar Arnfjörð Bjarmason" <avarab [at] gmail>
...
> Now that it's quietened down, I can ask a question. Does this I mean
> it's preferable to use
>
> $c->req->{parameters}->{foo}
>
> rather than
>
> $c->req->param('foo')
>
> Obviously I'd rather use the faster method but if I'm breaking the
> encapsulation in some ways that's going to bite me later, I'd steer
> clear.

> "Obviously".
>
> Unless you're doing method calls in a tight loop somewhere in your
> code you *shouldn't care about this*. Now I've written code that
> actually *did* suffer from method call overhead but since you're just
> casually asking it's very unlikely that you're doing the same.
>
> Don't sprinkle premature optimizations around your codebase just
> because someone produced a benchmark showing one is faster than the
> other. You should be doing *profiling* of your entire program, not
> micro-optimizing something that's likely 0.0001% of its total runtime.


If I remember well $c->req->param() is not recommended, but not for
performance reasons.

It resembles the method with the same name from CGI.pm, and it can return
not only a scalar value, but it could also return an array if it is called
in list context. So it might break the code if multiple values were sent for
the same variable.

Octavian


__________ Information from ESET NOD32 Antivirus, version of virus signature database 5061 (20100426) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


zzbbyy at gmail

Apr 26, 2010, 3:22 AM

Post #33 of 72 (4377 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Mon, Apr 26, 2010 at 10:57 AM, Ævar Arnfjörð Bjarmason
<avarab [at] gmail> wrote:
> On Mon, Apr 26, 2010 at 09:36, Dermot <paikkos [at] googlemail> wrote:
>> On 21 April 2010 18:01, J. Shirley <jshirley [at] gmail> wrote:
>>> __END__
>>> Benchmark: running all, low, sep for at least 1 CPU seconds...
>>>       all:  1 wallclock secs ( 1.11 usr +  0.00 sys =  1.11 CPU) @
>>> 2917341.44/s (n=3238249)
>>>       low:  0 wallclock secs ( 1.27 usr +  0.04 sys =  1.31 CPU) @
>>> 12930179.39/s (n=16938535)
>>>       sep:  1 wallclock secs ( 1.21 usr +  0.01 sys =  1.22 CPU) @
>>> 3223081.15/s (n=3932159)
>>>
>>> Subroutines suck, lets all use hashrefs.
>>
>> Now that it's quietened down, I can ask a question. Does this I mean
>> it's preferable to use
>>
>> $c->req->{parameters}->{foo}
>>
>> rather than
>>
>> $c->req->param('foo')
>>
>> Obviously I'd rather use the faster method but if I'm breaking the
>> encapsulation in some ways that's going to bite me later, I'd steer
>> clear.
>
> "Obviously".
>
> Unless you're doing method calls in a tight loop somewhere in your
> code you *shouldn't care about this*. Now I've written code that
> actually *did* suffer from method call overhead but since you're just
> casually asking it's very unlikely that you're doing the same.
>
> Don't sprinkle premature optimizations around your codebase just
> because someone produced a benchmark showing one is faster than the
> other. You should be doing *profiling* of your  entire program, not
> micro-optimizing something that's likely 0.0001% of its total runtime.
>

This is a fine advice - but unfortunately the ->param method call
suffers from additional problem - which is described in much detail in
the documentation (go to the NOTE at:
http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam).



--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


paikkos at googlemail

Apr 26, 2010, 3:41 AM

Post #34 of 72 (4377 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On 26 April 2010 11:22, Zbigniew Lukasiak <zzbbyy [at] gmail> wrote:
> On Mon, Apr 26, 2010 at 10:57 AM, var Arnfjr Bjarmason
> <avarab [at] gmail> wrote:
>> On Mon, Apr 26, 2010 at 09:36, Dermot <paikkos [at] googlemail> wrote:
>>> On 21 April 2010 18:01, J. Shirley <jshirley [at] gmail> wrote:
>>>> __END__
>>>> Benchmark: running all, low, sep for at least 1 CPU seconds...
>>>> all: 1 wallclock secs ( 1.11 usr + 0.00 sys = 1.11 CPU) @
>>>> 2917341.44/s (n=3238249)
>>>> low: 0 wallclock secs ( 1.27 usr + 0.04 sys = 1.31 CPU) @
>>>> 12930179.39/s (n=16938535)
>>>> sep: 1 wallclock secs ( 1.21 usr + 0.01 sys = 1.22 CPU) @
>>>> 3223081.15/s (n=3932159)
>>>>
>>>> Subroutines suck, lets all use hashrefs.
>>>
>>> Now that it's quietened down, I can ask a question. Does this I mean
>>> it's preferable to use
>>>
>>> $c->req->{parameters}->{foo}
>>>
>>> rather than
>>>
>>> $c->req->param('foo')
>>>
>>> Obviously I'd rather use the faster method but if I'm breaking the
>>> encapsulation in some ways that's going to bite me later, I'd steer
>>> clear.
>>
>> "Obviously".
>>
>> Unless you're doing method calls in a tight loop somewhere in your
>> code you *shouldn't care about this*. Now I've written code that
>> actually *did* suffer from method call overhead but since you're just
>> casually asking it's very unlikely that you're doing the same.

Why wouldn't you, as you write, use the the fastest access methods
available? Surely you'd want to develop habits that will a) provide
better performance and b) as mentioned below avoid the thorny
side-effects of req->params(). This isn't a matter of premature
optimisation but simply establishing good practise.

>> Don't sprinkle premature optimizations around your codebase just
>> because someone produced a benchmark showing one is faster than the
>> other. You should be doing *profiling* of your entire program, not
>> micro-optimizing something that's likely 0.0001% of its total runtime.


> This is a fine advice - but unfortunately the ->param method call
> suffers from additional problem - which is described in much detail in
> the documentation (go to the NOTE at:
> http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam)


I had seen this warning about the use of req->params() and lists.

So $c->params->{foo} is preferred [1].

That's fine. Thank you all.


1) ~/lib/Catalyst/Request.pm#$req->parameters

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


benvanstaveren at gmail

Apr 26, 2010, 4:00 AM

Post #35 of 72 (4379 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

> Why wouldn't you, as you write, use the the fastest access methods
> available? Surely you'd want to develop habits that will a) provide
> better performance and b) as mentioned below avoid the thorny
> side-effects of req->params(). This isn't a matter of premature
> optimisation but simply establishing good practise.
>
>
Because if you are working with, say, 10 people on a team, and you will
have everyone merrily doing direct hash accesses, sooner or later,
someone's going to fuck it up and something will break in a spectacular
fashion.

If you have methods to do this, the methods can check various things,
and throw out the proper errors.

Yes, a little bit of overhead -- the cost of hardware to compensate for
this overhead is still less than the cost of a fuckup that will keep
your app bugging for the rest of it's lifetime.

--
Ben van Staveren
phone: +62 81 70777529
email: benvanstaveren [at] gmail


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


publiustemp-catalyst at yahoo

Apr 26, 2010, 4:02 AM

Post #36 of 72 (4381 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

----- Original Message ----
> From: Dermot <paikkos [at] googlemail>


> Why wouldn't you, as you write, use the the fastest access methods
> available? Surely you'd want to develop habits that will a) provide
> better performance and b) as mentioned below avoid the thorny
> side-effects of req->params(). This isn't a matter of premature
> optimisation but simply establishing good practise.


This is a very common trap that many developers (even experienced ones) get caught up in. Let's make *everything* faster and our app is faster. A month of optimisation could easily result in no benefits because what developers think is slow rarely matches what *is* slow unless the developers have carefully profiled their application.

The problem, as has been pointed out, is that ENCAPSULATION is so terribly, terribly important -- and almost always more important that micro-optimisation -- that throwing away the known, constant benefits of encapsulation for unknown, occasional benefits of micro-optimisation would be a very, very bad idea for the community in general. It might be OK for you, but it's not OK for me. Without encapsulation, it's much harder to trust the correctness of my app.

In other words: give me a slower, but correct application over a faster, but unreliable one any day of the week.

Of course, if you can think of a way of dramatically improving the performance of the accessors without violating encapsulation, I'm sure patches would be gratefully received.

Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog - http://blogs.perl.org/users/ovid/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6



_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


paikkos at googlemail

Apr 26, 2010, 4:21 AM

Post #37 of 72 (4373 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On 26 April 2010 12:02, Ovid <publiustemp-catalyst [at] yahoo> wrote:
> ----- Original Message ----
>> From: Dermot <paikkos [at] googlemail>
>
>
>> Why wouldn't you, as you write, use the the fastest access methods
>> available? Surely you'd want to develop habits that will a) provide
>> better performance and b) as mentioned below avoid the thorny
>> side-effects of req->params(). This isn't a matter of premature
>> optimisation but simply establishing good practise.

> Because if you are working with, say, 10 people on a team, and you will have everyone merrily doing direct hash accesses, sooner or later, someone's going to fuck it up and something will break in a spectacular > fashion.

I take your point even though I am not in a team.

> This is a very common trap that many developers (even experienced ones) get caught up in. Let's make *everything* faster and our app is faster. A month of optimisation could easily result in no benefits because what developers think is slow rarely matches what *is* slow unless the developers have carefully profiled their application.
>
> The problem, as has been pointed out, is that ENCAPSULATION is so terribly, terribly important -- and almost always more important that micro-optimisation -- that throwing away the known, constant benefits of encapsulation for unknown, occasional benefits of micro-optimisation would be a very, very bad idea for the community in general. It might be OK for you, but it's not OK for me. Without encapsulation, it's much harder to trust the correctness of my app.

I don't want to break encapsulation and that was the point of the
question. Toby mentioned req->params->{} and that will be the method
I'll stick with. I simply want to try and use the methods that will
provide the most dividends and for that to become habitual.

Thanx,
Dp.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


benvanstaveren at gmail

Apr 26, 2010, 4:26 AM

Post #38 of 72 (4377 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

>> Because if you are working with, say, 10 people on a team, and you will have everyone merrily doing direct hash accesses, sooner or later, someone's going to fuck it up and something will break in a spectacular > fashion.
>>
>
> I take your point even though I am not in a team.
>
>
Even if you're not, direct hash accessing is basically akin to juggling
grenades. It might go right for a long time, but eventually the pin's
going to come out and there will be a very messy BLAM.

Even if it is code you just write for yourself, still doesn't hurt to
make sure you avoid the BLAM bit :)

--
Ben van Staveren
phone: +62 81 70777529
email: benvanstaveren [at] gmail


bobtfish at bobtfish

Apr 26, 2010, 10:04 AM

Post #39 of 72 (4340 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On 26 Apr 2010, at 10:36, Dermot wrote:
> Obviously I'd rather use the faster method but if I'm breaking the
> encapsulation in some ways that's going to bite me later, I'd steer
> clear.

Premature optimisation is the root of all evil.

I really really wouldn't be worrying about method call overhead vs
direct hash access until:

1) Your confident your code is using the correct algorithms (i.e. you
can bogosort a lot faster with direct access than methods - that
doesn't meant you're not still doing a bogosort!)

2) Optimising things that profile as slow in YOUR APPLICATION.

The speedup (in developer time) you get from using the highest level
interface / abstraction appropriate ALWAYS buys you enough extra time
to have a round of optimisation once your code works, and fixing the
_actual_ pain points is likely to give you many more gains than
writing your code you in a way you think (due to trivial synthetic
benchmarks) will be faster, but that takes longer.

It should be noted that Catalyst _SPED UP_ (on perl 5.10) when it was
ported to Moose.

Cheers
t0m


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


paulm at paulm

Apr 26, 2010, 11:24 AM

Post #40 of 72 (4369 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

> Even if you're not, direct hash accessing is basically akin to juggling
> grenades. It might go right for a long time, but eventually the pin's going
> to come out and there will be a very messy BLAM.
>
> Even if it is code you just write for yourself, still doesn't hurt to make
> sure you avoid the BLAM bit :)

(Replying in general, to the sense of this email which others have related too)

Dermot, to my reading at least, has been clear twice now that he was
asking specifically about how to retrieve parameters -- presumably not
coming to a web framework list for an unsolicited computer science
lecture on encapsulation...

I think it behooves us as a community to afford posters when they
clearly articulate a question and context, as Dermot has*, not to
treat them as complete noobs. It'd be a shame if folks became
reluctant to ask 'simple' questions for fear of half a dozen catalyst
old-skoolers delivering a sermon.

(Even these questions often reveal useful tidbits like the CGI compat hazard.)

Paul

* not the OP!

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


wbs at grepit

Apr 26, 2010, 12:48 PM

Post #41 of 72 (4362 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

(Replying in general, to the sense of this email which others have related
too)

>
> Dermot, to my reading at least, has been clear twice now that he was
> asking specifically about how to retrieve parameters -- presumably not
> coming to a web framework list for an unsolicited computer science
> lecture on encapsulation...
>
> I think it behooves us as a community to afford posters when they
> clearly articulate a question and context, as Dermot has*, not to
> treat them as complete noobs. It'd be a shame if folks became
> reluctant to ask 'simple' questions for fear of half a dozen catalyst
> old-skoolers delivering a sermon.
>
>
Sorry, it is akin to someone driving up to you while you are in a gas
station in a unleaded ford asking very nicely "Do you know where the diesel
pumps are"? The question is literate and well formed but in context implies
lack of understanding. I would choose to answer, "You know, are not
driving a diesel and putting unleaded in that car will break it -- the pumps
are over there". If you want unadulterated bits in response to questions go
read the source, if you ask here there are many people that actually read
the questions and respond with holistic information that may not be the
exact output you are looking for.

Second and more important, the responses are offered for free -- complaints
are considered a cost.

Kindest,
-Wade


montuori at gmail

Apr 26, 2010, 1:00 PM

Post #42 of 72 (4383 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Mon, Apr 26, 2010 at 3:48 PM, Wade Stuart <wbs [at] grepit> wrote:

> Sorry, it is akin to someone driving up to you while you are in a gas
> station in a unleaded ford asking very nicely "Do you know where the diesel
> pumps are"? The question is literate and well formed but in context implies
> lack of understanding.

Not if there's a spare can in the trunk for the backhoe. Everybody's
situation is different, and there's often a good reason for seemingly
"incorrect" questions.

k.

--
kevin montuori

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


paulm at paulm

Apr 26, 2010, 1:11 PM

Post #43 of 72 (4368 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Mon, Apr 26, 2010 at 12:48, Wade Stuart <wbs [at] grepit> wrote:
> (Replying in general, to the sense of this email which others have related
> too)
>>
>> Dermot, to my reading at least, has been clear twice now that he was
>> asking specifically about how to retrieve parameters -- presumably not
>> coming to a web framework list for an unsolicited computer science
>> lecture on encapsulation...
>>
>> I think it behooves us as a community to afford posters when they
>> clearly articulate a question and context, as Dermot has*, not to
>> treat them as complete noobs. It'd be a shame if folks became
>> reluctant to ask 'simple' questions for fear of half a dozen catalyst
>> old-skoolers delivering a sermon.
>>
>
> Sorry, it is akin to someone driving up to you while you are in a gas
> station in a unleaded ford asking very nicely "Do you know where the diesel
> pumps are"?

Except that it isn't:

"Obviously I'd rather use the faster method but if I'm breaking the
encapsulation in some ways that's going to bite me later, I'd steer
clear."

I don't know how much more of an articulate disclaimer you need.

> The question is literate and well formed but in context implies
> lack of understanding.

Except that he gave context & obvious (to me at least) understanding.

I agree in some situations it's clear the poster is asking something
where they need some steering and/or "XY Problem" but my call is that
we give posters some credit, esp where it's clearly due.

Paul

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


webmaster at cosmicperl

Apr 26, 2010, 1:30 PM

Post #44 of 72 (4377 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Paul Makepeace wrote:
> Except that he gave context & obvious (to me at least) understanding.
>
> I agree in some situations it's clear the poster is asking something
> where they need some steering and/or "XY Problem" but my call is that
> we give posters some credit, esp where it's clearly due.
>

Have to agree with Paul here. Keeping the newbies happy is vital for
growth and popularity, and unfortunately something too many Perl groups
overlook.


Lyle



_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


zzbbyy at gmail

Apr 26, 2010, 1:51 PM

Post #45 of 72 (4366 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Mon, Apr 26, 2010 at 1:26 PM, Ben van Staveren
<benvanstaveren [at] gmail> wrote:
>
> Because if you are working with, say, 10 people on a team, and you will have
> everyone merrily doing direct hash accesses, sooner or later, someone's
> going to fuck it up and something will break in a spectacular > fashion.
>
>
> I take your point even though I am not in a team.
>
>
>
> Even if you're not, direct hash accessing is basically akin to juggling
> grenades. It might go right for a long time, but eventually the pin's going
> to come out and there will be a very messy BLAM.
>
> Even if it is code you just write for yourself, still doesn't hurt to make
> sure you avoid the BLAM bit :)

If using ->params->{name} (i.e. the direct hash approach) is like
juggling grenades - then what is like using the ->param( 'name' ) way
of doing it?
I am asking this because your grenades analogy gives the impression
that you you are against doing direct hash access for every price -
but I think the general advice is that in this particular case using
the ->param( 'name' ) is worse than using the direct hash access.


--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jshirley at gmail

Apr 26, 2010, 1:58 PM

Post #46 of 72 (4361 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Mon, Apr 26, 2010 at 1:51 PM, Zbigniew Lukasiak <zzbbyy [at] gmail> wrote:
> On Mon, Apr 26, 2010 at 1:26 PM, Ben van Staveren
> <benvanstaveren [at] gmail> wrote:
>>
>> Because if you are working with, say, 10 people on a team, and you will have
>> everyone merrily doing direct hash accesses, sooner or later, someone's
>> going to fuck it up and something will break in a spectacular > fashion.
>>
>>
>> I take your point even though I am not in a team.
>>
>>
>>
>> Even if you're not, direct hash accessing is basically akin to juggling
>> grenades. It might go right for a long time, but eventually the pin's going
>> to come out and there will be a very messy BLAM.
>>
>> Even if it is code you just write for yourself, still doesn't hurt to make
>> sure you avoid the BLAM bit :)
>
> If using ->params->{name} (i.e. the direct hash approach) is like
> juggling grenades - then what is like using the ->param( 'name' ) way
> of doing it?
> I am asking this because your grenades analogy gives the impression
> that you you are against doing direct hash access for every price -
> but I think the general advice is that in this particular case using
> the ->param( 'name' ) is worse than using the direct hash access.
>
>

I believe the discussion is about $c->req->{parameters}->{name}, not
about using ->params->{name}, isn't it?

Analogies to grenades, gas pumps and whatever else are just silly. We
all understand software development sufficiently well enough to simply
talk at the matter at hand.

Violating encapsulation in a local, protected scope for purposes of
efficiency is ok.
Violating encapsulation on a global scope is not, for a variety of
reasons, the most obvious of which is you have no contract for data
access.

I don't believe that $c->req->params violates any ideas, since the
parameters is nothing more than a hashref. How you get that hashref,
though, is a binding contract to the request. Calling
$c->req->{params} is an evil, naughty thing.

-J

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


swatt at infobal

Apr 26, 2010, 2:16 PM

Post #47 of 72 (4362 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Part of the point, surely, is that we don't (want to) know what is
inside $c/$c->request (or any other Catalyst structure). The "direct
hash" could easily be a tied something-or-other inside, as is the case
with CGI when you use the Vars accessor. So just because it looks like a
direct hash, you can't from the outside assume it is more efficient. In
CGI, for example, the tied hash accessors (if you use Vars) are defined
in terms of the param method, so this mechanism is actually less
efficient than using param calls directly.

The point is: we can't/I wouldn't make assumptions about efficiency
based on the appearance of code, at least not in a language like Perl
where there can be so much magic behind the calling conventions.

If there is a recommended way of doing this, I'd certainly want to know
it. And it would probably help if that was efficient, but so long as it
doesn't leak or expose internal hackery, it shouldn't really matter. And
if it does, then it should probably be deprecated or documented so we
can avoid problems.

Perhaps it would have been better if the internal hash keys had been the
usual private-style "_parameters", etc., as that way everyone would know
direct access as a no-no, because the accessors would work but not the
direct access.

--S
--
Stuart Watt
ARM Product Developer
Information Balance


pagaltzis at gmx

Apr 26, 2010, 2:59 PM

Post #48 of 72 (4365 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

* Zbigniew Lukasiak <zzbbyy [at] gmail> [2010-04-26 12:25]:
> This is a fine advice - but unfortunately the ->param method
> call suffers from additional problem - which is described in
> much detail in the documentation (go to the NOTE at:
> http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam).

Yeah, but the ->params hash has the converse problem: if you
write

$c->model->insert_person( name => $c->req->params->{'name'} )

then you may be surprised to find out there are people with name
like ARRAY(0xDEADBEEF). Of course that’s just a relatively minor
case of data corruption. Worse is if you legitimately expect
a parameter to have one or more values, eg. a pile of checkboxes.
Then you have to constantly check whether you’re getting a scalar
or an array reference.

So either you use the legacy method and have to protect against
getting more values than you wanted, or you use the suggested
method and have to protect against getting fewer values than you
expect in the general case.

I briefly tried to write something to stick Hash::MultiValue into
Catalyst to end the madness, but doing it properly would require
a plugin, plus HTTP::BodyParser (I think) was using a misdesigned
approach that made deep integration of H::MV impossible (with
properly preserved k/v pair order).

Could have written a Request role… but that seemed unsatisfying.

I wonder whether it would be possible to rip out the respective
bits from Cat and use just H::MV, and leave the current stuff to
a compat plugin or something like that…

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


benvanstaveren at gmail

Apr 26, 2010, 6:55 PM

Post #49 of 72 (4349 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Hi Paul,

Don't get me wrong, but my opinion is pretty much opposite from yours,
if people come and ask a good question (which Dermot did), and seem to
be -not- total noobs, then they get a free CompSci lesson to go with the
answer they've gotten :)

Maybe that's just me, but I always like knowing -why- a certain answer
was given - besides just the "this is how it should be" kind of answer :)

Anyways, he got both the answer he was looking for, and some tips from
people - perhaps some of us feel more strongly about it than others, but
hey, that's what makes things interesting no?

Paul Makepeace wrote:
>> Even if you're not, direct hash accessing is basically akin to juggling
>> grenades. It might go right for a long time, but eventually the pin's going
>> to come out and there will be a very messy BLAM.
>>
>> Even if it is code you just write for yourself, still doesn't hurt to make
>> sure you avoid the BLAM bit :)
>>
>
> (Replying in general, to the sense of this email which others have related too)
>
> Dermot, to my reading at least, has been clear twice now that he was
> asking specifically about how to retrieve parameters -- presumably not
> coming to a web framework list for an unsolicited computer science
> lecture on encapsulation...
>
> I think it behooves us as a community to afford posters when they
> clearly articulate a question and context, as Dermot has*, not to
> treat them as complete noobs. It'd be a shame if folks became
> reluctant to ask 'simple' questions for fear of half a dozen catalyst
> old-skoolers delivering a sermon.
>
> (Even these questions often reveal useful tidbits like the CGI compat hazard.)
>
> Paul
>
> * not the OP!
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>
>

--
Ben van Staveren
phone: +62 81 70777529
email: benvanstaveren [at] gmail


benvanstaveren at gmail

Apr 26, 2010, 7:00 PM

Post #50 of 72 (4354 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

> If using ->params->{name} (i.e. the direct hash approach) is like
> juggling grenades - then what is like using the ->param( 'name' ) way
> of doing it?
>
Actually ->params->{name} is the juggling teddybears one (the "proper"
way to do it). If you do $c->{request}->{params}->{name} - that's the
grenade way.

-.param('name') is juggling sharp knives :)

> I am asking this because your grenades analogy gives the impression
> that you you are against doing direct hash access for every price -
> but I think the general advice is that in this particular case using
> the ->param( 'name' ) is worse than using the direct hash access.
>
Sorry if I wasn't quite clear on it, in the specific case of
$c->req->params and consorts, doing $c->req->params->{ ... } is the
"right" way to do it, after all, params returns a hashref and offers no
further encapsulation; using ->req->param('foo') would work, but is just
a compatibility shim for CGI and comes with some major drawbacks.

I was, however, speaking in general; it's often better to be able to do
$object->get_foo/$object->set_foot (or $object->foo which does both),
than to go $object->{foo} = ...;

In some cases, it's not, sometimes you need to get rid of the overhead,
but the common "idea" at that point is that IF you need to break
encapsulation, comment it right, and indicate WHY you're doing it.


>
>

--
Ben van Staveren
phone: +62 81 70777529
email: benvanstaveren [at] gmail


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


zzbbyy at gmail

Apr 27, 2010, 12:12 AM

Post #51 of 72 (4514 views)
Permalink
Re: Re: Alternatives to Catalyst ? [In reply to]

On Mon, Apr 26, 2010 at 11:59 PM, Aristotle Pagaltzis <pagaltzis [at] gmx> wrote:
> * Zbigniew Lukasiak <zzbbyy [at] gmail> [2010-04-26 12:25]:
>> This is a fine advice - but unfortunately the ->param method
>> call suffers from additional problem - which is described in
>> much detail in the documentation (go to the NOTE at:
>> http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam).
>
> Yeah, but the ->params hash has the converse problem: if you
> write
>
>    $c->model->insert_person( name => $c->req->params->{'name'} )
>
> then you may be surprised to find out there are people with name
> like ARRAY(0xDEADBEEF). Of course that’s just a relatively minor
> case of data corruption. Worse is if you legitimately expect
> a parameter to have one or more values, eg. a pile of checkboxes.
> Then you have to constantly check whether you’re getting a scalar
> or an array reference.
>
> So either you use the legacy method and have to protect against
> getting more values than you wanted, or you use the suggested
> method and have to protect against getting fewer values than you
> expect in the general case.
>
> I briefly tried to write something to stick Hash::MultiValue into
> Catalyst to end the madness, but doing it properly would require
> a plugin, plus HTTP::BodyParser (I think) was using a misdesigned
> approach that made deep integration of H::MV impossible (with
> properly preserved k/v pair order).
>
> Could have written a Request role… but that seemed unsatisfying.
>
> I wonder whether it would be possible to rip out the respective
> bits from Cat and use just H::MV, and leave the current stuff to
> a compat plugin or something like that…

Not a very concrete answer - but I remember that Miyagawa talked about
fixing that in Plack::Request (and I am not sure but I think it also
involved H::MV) - so there might be some occasion for reuse :)

Cheers,
Z.

>
> Regards,
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>



--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


merlyn at zynet

Apr 27, 2010, 2:14 AM

Post #52 of 72 (4515 views)
Permalink
RE: Alternatives to Catalyst ? [In reply to]

I'm running out of popcorn now so here's a quick summary of my observations
WRT getting request parameters:

- If a simple question about something so fundamental to what Catalyst is
for (i.e. Dermot's question, not Oleg's) can generate so much debate then
something's not right somewhere. Hopefully, in the docs.

- Three methods of getting CGI parameters have been mentioned:
- $c->req->{parameters}->{name}
Undocumented, dangerous, used only by lunatics and trolls.
- $c->req->param(name)
Documented legacy interface, deprecated (but unfortunately the only
one mentioned in Catalyst/Manual/Intro.pod#Query_Parameter_Processing).
- $c->req->param[eter]s->{name}
The correct encapsulation - use this.

- CS101: premature optimisation is the root of much evil but OTOH it's a
good idea to be in the habit of using optimal methods when there's a choice
not dictated by other factors. But that's not actually relevant here.

- It's nice to answer people's questions without making assumptions about
their context. OTOH additional advice which turns out to be irrelevant is
free so we shouldn't scorn it. OTOH it can be off-putting to people trying
find their way through the information overload as they start using a new
system as complex as Catalyst. OTOH complaining about it just causes bad
feeling so we shouldn't do that. OTOH complaining about complaints is no
different from complaining about anything else. OTOH this loop has no exit
condition. break;

So I had a quick look at the docs (for the first time in many years - I
found them at http://search.cpan.org/~hkclark/Catalyst-Manual/) to see if I
could see what this is all about. The answer to Dermot's question is there
but it it's a bit obscured by the CGI.pm combatability aspect - that was
very important at the start of Catalyst's life (because most users would be
coming from there) but probably isn't so much any more. In particular, as
mentioned above, Catalyst/Manual/Intro.pod#Query_Parameter_Processing really
only talks about the req->param() interface. I propose that all references
to the req->param() interface should be replaced by references to the
$c->req->parameters->{} interface except where explicit discussions of
CGI.pm compatability are appropriate, which would only be very briefly in
the case of the Intro. I'm afraid I don't know how to do this but if someone
sends me a pointer to instructions I'll have a go at making a doc patch or
whatever's appropriate.

Merlyn


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


syber.rus at gmail

Apr 27, 2010, 2:39 AM

Post #53 of 72 (4513 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

2010/4/27 J. Shirley <jshirley [at] gmail>:
> On Mon, Apr 26, 2010 at 1:51 PM, Zbigniew Lukasiak <zzbbyy [at] gmail> wrote:
>> On Mon, Apr 26, 2010 at 1:26 PM, Ben van Staveren
>> <benvanstaveren [at] gmail> wrote:
>>>
>>> Because if you are working with, say, 10 people on a team, and you will have
>>> everyone merrily doing direct hash accesses, sooner or later, someone's
>>> going to fuck it up and something will break in a spectacular > fashion.
>>>
>>>
>>> I take your point even though I am not in a team.
>>>
>>>
>>>
>>> Even if you're not, direct hash accessing is basically akin to juggling
>>> grenades. It might go right for a long time, but eventually the pin's going
>>> to come out and there will be a very messy BLAM.
>>>
>>> Even if it is code you just write for yourself, still doesn't hurt to make
>>> sure you avoid the BLAM bit :)
>>
>> If using ->params->{name} (i.e. the direct hash approach) is like
>> juggling grenades - then what is like using the ->param( 'name' ) way
>> of doing it?
>> I am asking this because your grenades analogy gives the impression
>> that you you are against doing direct hash access for every price -
>> but I think the general advice is that in this particular case using
>> the ->param( 'name' ) is worse than using the direct hash access.
>>
>>
>
> I believe the discussion is about $c->req->{parameters}->{name}, not
> about using ->params->{name}, isn't it?
>
> Analogies to grenades, gas pumps and whatever else are just silly. We
> all understand software development sufficiently well enough to simply
> talk at the matter at hand.
>
> Violating encapsulation in a local, protected scope for purposes of
> efficiency is ok.
> Violating encapsulation on a global scope is not, for a variety of
> reasons, the most obvious of which is you have no contract for data
> access.
>
> I don't believe that $c->req->params violates any ideas, since the
> parameters is nothing more than a hashref. How you get that hashref,
> though, is a binding contract to the request. Calling
> $c->req->{params} is an evil, naughty thing.

Why can't nobody understand, the question is not why someone should
use "$c->req->{params}". Of course that is an evil. Problem is that if
i could get ->{parameters}{name} at a speed 100x there can't be no
reason for ->params to work as a turtle and i see a good reason to use
wrappers around Request to provide normal, fast method of acessing
parameters. Use Class::XSAccessor, Fast::XS, i dont now, use
something!!! Many people ask me why most of catalyst accessors working
so slow ? i dunno what to answer except for writing our own wrapper
accessors getting values directly with massive speedup.

>
> -J
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


bobtfish at bobtfish

Apr 27, 2010, 2:44 AM

Post #54 of 72 (4513 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Merlyn Kline wrote:
> So I had a quick look at the docs (for the first time in many years - I
> found them at http://search.cpan.org/~hkclark/Catalyst-Manual/) to see if I
> could see what this is all about. The answer to Dermot's question is there
> but it it's a bit obscured by the CGI.pm combatability aspect - that was
> very important at the start of Catalyst's life (because most users would be
> coming from there) but probably isn't so much any more. In particular, as
> mentioned above, Catalyst/Manual/Intro.pod#Query_Parameter_Processing really
> only talks about the req->param() interface. I propose that all references
> to the req->param() interface should be replaced by references to the
> $c->req->parameters->{} interface except where explicit discussions of
> CGI.pm compatability are appropriate, which would only be very briefly in
> the case of the Intro.

+1 Agree.

> I'm afraid I don't know how to do this but if someone
> sends me a pointer to instructions I'll have a go at making a doc patch or
> whatever's appropriate.

Well volunteered! Check out:

http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Manual/5.80/trunk/

And either make changes and stick a diff in the RT queue, or stop by
#catalyst-dev on irc and ask for a commit-bit to commit your changes
yourself :)

Cheers
t0m



_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


pagaltzis at gmx

Apr 27, 2010, 3:07 AM

Post #55 of 72 (4522 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

* Zbigniew Lukasiak <zzbbyy [at] gmail> [2010-04-27 09:20]:
> Not a very concrete answer - but I remember that Miyagawa
> talked about fixing that in Plack::Request (and I am not sure
> but I think it also involved H::MV) - so there might be some
> occasion for reuse :)

Yeah, that’s exactly what he wrote H::MV for. I chimed in a bit,
and the way its internal storage works now fell out of a back
& forth between the two of us, designed for the typical use case
in web apps – it’s optimised for initialisation speed at the
expense of query speed, because you typically only ask for param
values once anyway, and the initialisation cost is incurred for
every request no matter how little of its effort you exploit.
(So people who randomly microbenchmark querying, like the thread
starter, will be unhappy about that… just goes to show the
fallacy of doing that.)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


catalyst at fadetoblack

Apr 27, 2010, 3:43 AM

Post #56 of 72 (4509 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Merlyn Kline wrote:
> I propose that all references
> to the req->param() interface should be replaced by references to the
> $c->req->parameters->{} interface except where explicit discussions
> of CGI.pm compatability are appropriate, which would only be very
> briefly in the case of the Intro.

It's not just useful for new users reading the intro with a CGI.pm
background.

There are other useful modules on CPAN that will process incoming request
parameters, that have been designed to expect a CGI object that they can
call param on. When using those modules with Cat it's handy to be able to
pass the Cat Request object over to make them work the same.

Carl


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


catalyst at fadetoblack

Apr 27, 2010, 4:09 AM

Post #57 of 72 (4506 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Dermot wrote:
> Why wouldn't you, as you write, use the the fastest access methods
> available? Surely you'd want to develop habits that will a) provide
> better performance and b) as mentioned below avoid the thorny
> side-effects of req->params(). This isn't a matter of premature
> optimisation but simply establishing good practise.

Answering this in the general case.

If you know that the object is stored as a hash, yes you can access it like
a hash - but that's your risk. When you upgrade your modules and it switches
to being stored some other way - you get to fix all your code. That's one of
the things that many perl coders like - to the degree that it's perl
culture - you *can* poke inside the box if you want but you have to accept
the risks that go with that.

As far as other optimisations, yes it's nice to develop some good habits but
you don't want that to be at the expense of maintainability. Even if you're
a team of one - you will still have to come back and maintain your own code
at some future time. I have plenty of code that I wrote and understood very
well at the time, but is a confusing mess now! So if an optimisation doesn't
impact maintenance too much it's worth turning into a habit. eg print with a
list rather than using concatination

Carl


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


paikkos at googlemail

Apr 27, 2010, 5:22 AM

Post #58 of 72 (4505 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On 27 April 2010 12:09, Carl Johnstone <catalyst [at] fadetoblack> wrote:
> Dermot wrote:
>> Why wouldn't you, as you write, use the the fastest access methods
>> available? Surely you'd want to develop habits that will a) provide
>> better performance and b) as mentioned below avoid the thorny
>> side-effects of req->params(). This isn't a matter of premature
>> optimisation but simply establishing good practise.
>
> Answering this in the general case.
>
> If you know that the object is stored as a hash, yes you can access it like
> a hash - but that's your risk. When you upgrade your modules and it switches
> to being stored some other way - you get to fix all your code. That's one of
> the things that many perl coders like - to the degree that it's perl
> culture - you *can* poke inside the box if you want but you have to accept
> the risks that go with that.

[meh] I was really trying to avoid coming back into this thread but I
feel I have to make clear what I was asking. There is this assumption
that I *wanted* to break encapsulation. That wasn't the case. I
started from J.Shirely's point. That's was why I left that extract in.

> Benchmark: running all, low, sep for at least 1 CPU seconds...
> all: 1 wallclock secs ( 1.11 usr + 0.00 sys = 1.11 CPU) @
> 2917341.44/s (n=3238249)
> low: 0 wallclock secs ( 1.27 usr + 0.04 sys = 1.31 CPU) @
> 12930179.39/s (n=16938535)
> sep: 1 wallclock secs ( 1.21 usr + 0.01 sys = 1.22 CPU) @
> 3223081.15/s (n=3932159)
>
> Subroutines suck, lets all use hashrefs.

That comment was obviously tongue in cheek but there was an
underlining point that access via sub-routine reference is slower than
access via a hash. Toby was quick to point out that as far as he knew
$req->param->{} was the referred method. Now that doesn't break
encapsulation and I'm assuming that it will be faster access method
than $req->params(). I could be wrong. I haven't benchmarked. I am
simply following the logic that subroutine references are slower that
hash lookups. Is it really so wrong to want to use params->{} over
params()? You may call it premature optimisation (as if is a dirty
word) but to me it's just a good habit that has the benefits of being
a bit faster.

So just in case you missed it, when I said:

...but if I'm breaking the encapsulation in some ways that's going to
bite me later, I'd steer
clear.

I meant, "I'd don't want break encapsulation".

I hope that clear things up and you can stop talking about me as if
I'm not here :)

Thanx,
Dp

PS: It goes without saying that I agree with Paul's point.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


jshirley at gmail

Apr 27, 2010, 7:14 AM

Post #59 of 72 (4494 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Tue, Apr 27, 2010 at 2:39 AM, Oleg Pronin <syber.rus [at] gmail> wrote:

> Why can't nobody understand, the question is not why someone should
> use "$c->req->{params}". Of course that is an evil. Problem is that if
> i could get ->{parameters}{name} at a speed 100x there can't be no
> reason for ->params to work as a turtle and i see a good reason to use
> wrappers around Request to provide normal, fast method of acessing
> parameters. Use Class::XSAccessor, Fast::XS, i dont now, use
> something!!! Many people ask me why most of catalyst accessors working
> so slow ? i dunno what to answer except for writing our own wrapper
> accessors getting values directly with massive speedup.
>

The response you are getting, and having a hard time understanding
apparently, is that the worrying about overhead of accessors is
premature optimization that has no benefit to the scope of your real
application.

Unless you provide a NYTProf of your application showing Catalyst is
the bottleneck, nobody is going to care what you are saying.

I'm not sure why you think Catalyst accessors are so slow... on 5.10+
they are faster than Class::Accessor::Fast. Startup time is slower,
but runtime is faster. I'd prefer that.

Oleg, seriously, what are you trying to accomplish here? You aren't
saying anything helpful and you really aren't good at trolling. I'm
genuinely curious about your goals and the only reason I (and others)
are bothering to respond to you because your history on the mailing
list.

-J

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


garrison at zeta

Apr 27, 2010, 8:12 AM

Post #60 of 72 (4488 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Good morning,

On 27/04/10 at 1:22 PM +0100, Dermot <paikkos [at] googlemail> wrote:

>That comment was obviously tongue in cheek but there was an
>underlining point that access via sub-routine reference is slower than
>access via a hash. Toby was quick to point out that as far as he knew
>$req->param->{} was the referred method. Now that doesn't break
>encapsulation and I'm assuming that it will be faster access method
>than $req->params(). I could be wrong. I haven't benchmarked. I am
>simply following the logic that subroutine references are slower that
>hash lookups. Is it really so wrong to want to use params->{} over
>params()? You may call it premature optimisation (as if is a dirty
>word) but to me it's just a good habit that has the benefits of being
>a bit faster.
>
>So just in case you missed it, when I said:
>
>...but if I'm breaking the encapsulation in some ways that's going to
>bite me later, I'd steer
>clear.
>
>I meant, "I'd don't want break encapsulation".
>
>I hope that clear things up and you can stop talking about me as if
>I'm not here :)

That didn't clear things up for me, and I thought I had some
clarity already. So I guess one of us is (still) confused.

I thought it was an issue of:

$req->param(...)

vs:

$req->params->{...}

Note, one is plural, the other is not. The param method is for
legacy CGI.pm compatibility, and as such, is slower. The params
method returns a hash, and of course one then does direct hash lookups.

The params method is an alias for parameters. And since it
simply returns a hash it is relatively speedy and encapsulates
the internal parameters access (hash or whatever) within C::Request.

And for those who like juggling with sharp knives with one hand,
they could skip both param and params methods and use:

$req->{parameters}->{...}


So as long as one doesn't need CGI.pm compat, use
$req->params->{...} as the 'best practices' approach. It's not
slower like $req->param(...) is, but still offers the desired encapsulation.

Have I got that right or am I still confused?

My mental clue sheet looks like this:

$req->param(...) will return one value (scalar or array),
the way I'm used to with CGI.pm.
$req->params->{...} returns multiple values in a hash,
which I can then reference by key.

One thing this discussion did help me with was some confusion
that HTML::FormFu threw in there for me. In my mind, I kept
confusing its $form->param(...) (& related) methods with
$req->params->{...}. This discussion has resulted in me
reviewing my usage of all various param(s) methods and I've
found a few things to fix (or improve).

I hope I've got it right now. :-)


Charlie

--
Ꮚ Charlie Garrison ♊ <garrison [at] zeta>

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
http://www.ietf.org/rfc/rfc1855.txt

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


tobias.kremer at gmail

Apr 27, 2010, 8:29 AM

Post #61 of 72 (4490 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Tue, Apr 27, 2010 at 5:12 PM, Charlie Garrison <garrison [at] zeta> wrote:
> So as long as one doesn't need CGI.pm compat, use $req->params->{...} as the
> 'best practices' approach. It's not slower like $req->param(...) is, but
> still offers the desired encapsulation.
> Have I got that right or am I still confused?

Exactly! :)

Also, $c->req->param(..) _CAN_ be a security issue when blindly used
in a DBIC search() method. We discussed this a while ago:
http://www.gossamer-threads.com/lists/catalyst/users/24255

--Tobias

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


mromani at ottotecnica

Apr 27, 2010, 11:46 PM

Post #62 of 72 (4427 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

J. Shirley ha scritto:
> On Tue, Apr 27, 2010 at 2:39 AM, Oleg Pronin <syber.rus [at] gmail> wrote:
>
>> Why can't nobody understand, the question is not why someone should
>> use "$c->req->{params}". Of course that is an evil. Problem is that if
>> i could get ->{parameters}{name} at a speed 100x there can't be no
>> reason for ->params to work as a turtle and i see a good reason to use
>> wrappers around Request to provide normal, fast method of acessing
>> parameters. Use Class::XSAccessor, Fast::XS, i dont now, use
>> something!!! Many people ask me why most of catalyst accessors working
>> so slow ? i dunno what to answer except for writing our own wrapper
>> accessors getting values directly with massive speedup.
>>
>
> The response you are getting, and having a hard time understanding
> apparently, is that the worrying about overhead of accessors is
> premature optimization that has no benefit to the scope of your real
> application.
>
> Unless you provide a NYTProf of your application showing Catalyst is
> the bottleneck, nobody is going to care what you are saying.
>
> I'm not sure why you think Catalyst accessors are so slow... on 5.10+
> they are faster than Class::Accessor::Fast. Startup time is slower,
> but runtime is faster. I'd prefer that.
>
> Oleg, seriously, what are you trying to accomplish here? You aren't
> saying anything helpful and you really aren't good at trolling. I'm
> genuinely curious about your goals and the only reason I (and others)
> are bothering to respond to you because your history on the mailing
> list.
>
> -J
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/

But the question arises: is he the _real_ Oleg Pronin... ?

--
Marcello Romani

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


mst at shadowcat

Apr 28, 2010, 7:40 AM

Post #63 of 72 (4402 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On Tue, Apr 27, 2010 at 01:39:44PM +0400, Oleg Pronin wrote:
> Why can't nobody understand, the question is not why someone should
> use "$c->req->{params}". Of course that is an evil. Problem is that if
> i could get ->{parameters}{name} at a speed 100x there can't be no
> reason for ->params to work as a turtle and i see a good reason to use
> wrappers around Request to provide normal, fast method of acessing
> parameters. Use Class::XSAccessor, Fast::XS, i dont now, use
> something!!! Many people ask me why most of catalyst accessors working
> so slow ? i dunno what to answer except for writing our own wrapper
> accessors getting values directly with massive speedup.

You know, in the entire time I've been working on Catalyst apps (and bear
in mind Shadowcat have been a largely specialist Catalyst/DBIx::Class
consultancy for four years plus now) I have never, ever seen the speed
of methods on $c->req show up as a bottleneck.

I've never even seen them show up on pre-5.80 Catalyst where the accessors
were *slower* than they are now (which is why I find your comment about Moose
and hardware manufacturers to be ... unsupportable) - and as such I am unable
to understand why you're complaining now rather than back then.

Why can't -you- understand that the question is why you think a microbenchmark
of a method that should only be called a handful of times per request - and
has never, ever, shown up as a bottleneck for any of the developers on this
list - is remotely relevant and in any way a problem?

use strict;

is significantly slower than

BEGIN { $^H |= 0x602; }

but that doesn't count as an argument to use the second form instead unless
that import() call is genuinely a bottleneck in your application.

Premature optimisation is the root of much evil. Profiles of this being
a genuine problem for real production code or GTFO, please.

--
Matt S Trout Catalyst and DBIx::Class consultancy with a clue
Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/
Shadowcat Systems Limited
mst (@) shadowcat.co.uk http://shadowcat.co.uk/blog/matt-s-trout/

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


akovbovich at gmail

Apr 28, 2010, 10:43 AM

Post #64 of 72 (4397 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

I was curious about what the big deal is raised, so spent a short test.

*** Mojo *** (Alternative to Catalyst)
timethese(-1, {
param => sub { $tx->req->param('lang') },
params => sub { $tx->req->params->param('lang') },
});

Benchmark: running param, params for at least 1 CPU seconds...
param: 1 wallclock secs ( 1.07 usr + 0.00 sys = 1.07 CPU) @
13397.20/s (n=14335)
params: 1 wallclock secs ( 1.08 usr + 0.00 sys = 1.08 CPU) @
8295.37/s (n=8959)

*** Cat ***
timethese(-1, {
param => sub { $c->req->param('lang') },
params => sub { $c->req->params->{'lang'} },
});

Benchmark: running param, params for at least 1 CPU seconds...
param: 1 wallclock secs ( 1.06 usr + 0.01 sys = 1.07 CPU) @
30918.69/s (n=33083)
params: 1 wallclock secs ( 1.07 usr + 0.01 sys = 1.08 CPU) @
79643.52/s (n=86015)

My Сat app can handle about 400req/s, at the same time accessor's
access time is about 80K req/s, so if we imagine that we have not
made a single call to $req->param, in that case app will handle
402req/s. Show me the idiot who will try to optimize all the code for
such trifles?

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


syber.rus at gmail

Apr 29, 2010, 2:06 AM

Post #65 of 72 (4343 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

1) param is called often several times (in auto/end etc)
2) The question is not about params, but about accessors speed at all.
If all acessors were XSAccessor for example (catalyst makes a lot of
calls ->stack/action/dispatcher , etc internally during request), then
your overall speed would be 600/s i think)
3) The question is also in approach to programming.
Why someone writes
$c->req->...
$c->req->...
$c->req->...
If you know that $c->req is not a fast accessor why do you call it
several times?

Is it hard to write ?
my $req = $c->req;
$req->
$req->
...

Maybe it is not the bottleneck, but how many places do we have
like this that are "not a bottleneck" ? maybe the sum of all these
"mini" mistakes is the bottleneck ?

2010/4/28 . <akovbovich [at] gmail>:
> I was curious about what the big deal is raised, so spent a short test.
>
> *** Mojo *** (Alternative to Catalyst)
> timethese(-1, {
> param => sub { $tx->req->param('lang') },
> params => sub { $tx->req->params->param('lang') },
> });
>
> Benchmark: running param, params for at least 1 CPU seconds...
> param: 1 wallclock secs ( 1.07 usr + 0.00 sys = 1.07 CPU) @
> 13397.20/s (n=14335)
> params: 1 wallclock secs ( 1.08 usr + 0.00 sys = 1.08 CPU) @
> 8295.37/s (n=8959)
>
> *** Cat ***
> timethese(-1, {
> param => sub { $c->req->param('lang') },
> params => sub { $c->req->params->{'lang'} },
> });
>
> Benchmark: running param, params for at least 1 CPU seconds...
> param: 1 wallclock secs ( 1.06 usr + 0.01 sys = 1.07 CPU) @
> 30918.69/s (n=33083)
> params: 1 wallclock secs ( 1.07 usr + 0.01 sys = 1.08 CPU) @
> 79643.52/s (n=86015)
>
> My at app can handle about 400req/s, at the same time accessor's
> access time is about 80K req/s, so if we imagine that we have not
> made a single call to $req->param, in that case app will handle
> 402req/s. Show me the idiot who will try to optimize all the code for
> such trifles?
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


m.blackman at fairfx

Apr 29, 2010, 2:18 AM

Post #66 of 72 (4342 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On 29 Apr 2010, at 10:06, Oleg Pronin wrote:
>
> Maybe it is not the bottleneck, but how many places do we have
> like this that are "not a bottleneck" ? maybe the sum of all these
> "mini" mistakes is the bottleneck ?

Do the profiling, answer the "maybe" question.

- Mark


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


diment at gmail

Apr 29, 2010, 2:26 AM

Post #67 of 72 (4327 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On 29/04/2010, at 7:06 PM, Oleg Pronin wrote:

> [...]
> Maybe it is not the bottleneck, but how many places do we have
> like this that are "not a bottleneck" ? maybe the sum of all these
> "mini" mistakes is the bottleneck ?

I've done some research on this topic, not from a computer science POV, but from the business end. Of the popular web frameworks, Catalyst clearly runs some extremely popular websites, in a variety of sectors. If the micro-bottlenecks were a problem for achieving scale, then Catalyst would not be usable for these entities. Catalyst hits the sweet spot for lone coders like me, who use it to manage some kinds of messy research data (e.g. http://github.com/singingfish/Text-TranscriptMiner-Web) to mainstream content providers like the BBC, entities in the adult industry (always bandwidth hogs) and social media providers. In both cases it's the speed of the development cycle, and the ease with which it's possible to optimise around pain points on a case by case basis that is the main benefit.

So I'm really don't think your argument has substance.
_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


catalyst at fadetoblack

Apr 29, 2010, 2:32 AM

Post #68 of 72 (4332 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Oleg Pronin wrote:
> Maybe it is not the bottleneck, but how many places do we have
> like this that are "not a bottleneck" ? maybe the sum of all these
> "mini" mistakes is the bottleneck ?

NYTProf profile or it didn't happen :-)

Carl


_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


matija at serverflow

Apr 29, 2010, 3:04 AM

Post #69 of 72 (4330 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

Carl Johnstone wrote:
> NYTProf profile or it didn't happen :-)
>
Is there any "best practices" or hints page on how to use Catalyst and
NYTprof? I haven't used it before and I wonder if people include it
into a running catalyst application (and then periodically review
results in some way) or if they include it only into a
just-for-profiling server which then runs a synthetic load? Or something
in between?

I've had some problems with a catalyst application lately, but it turned
out that it was caused by the FCGI servers being swapped out: no ammount
of tweaking my code would have solved it, all it took was an extra
$10/month for another 256M RAM.

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


toby.corkindale at strategicdata

Apr 29, 2010, 3:07 AM

Post #70 of 72 (4326 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

On 29/04/10 19:06, Oleg Pronin wrote:
> Maybe it is not the bottleneck, but how many places do we have
> like this that are "not a bottleneck" ? maybe the sum of all these
> "mini" mistakes is the bottleneck ?


Hi Oleg,
Do you have an application which *has* a bottleneck at the moment? If
so, can you demonstrate it?

Quite a lot of people on this list are trying to tell you that Catalyst
runs some very big sites quite successfully, and my own experience backs
that up.

Whenever I've hit a bottleneck in a site, it has turned out to be:
* Database calls (usually with expensive queries)
* Poorly designed TT templates
* Stupid blocking calls in a controller (eg. sleep, system, waitpid, etc)
* Network bandwidth

But NOT the speed of accessor methods in Catalyst. They really are not
an issue.

If you *do* have a performance issue yourself, then please feel free to
bring up a specific example, but otherwise, quit worrying.

If you are concerned that you're not squeezing the absolute most
performance out of every clock cycle on your CPU, then you should go
back to coding in raw assembler instead of Perl, but it's not worth
hassling us about.

Cheers,
Toby

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/


swatt at infobal

Apr 29, 2010, 6:57 AM

Post #71 of 72 (4317 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

I was kind of hoping this thread would get to more helpful issues. It
did, and thanks.

It's hard for us to profile a running application, for several reasons.
(1) there is a web server in the way, and (2) the storage requirements
(and to some extent performance) are a hit. Also, a management
requirement was obfuscation that turns off debugging hooks needed for
NYTProf, so our production code cannot really be profiled. However, we
do audit mean response times for each view, and I have a few bits of
charting code in R that allow us to report on it.

We actually run a test script that models a proper workflow. This
happened because my colleagues require an old Perl tool "webinject" for
QA. I ripped the back off webinject,. stuck Catalyst::Test in its place,
and then run NYTProf on the whole thing. That way we have files that
script a fairly realistic set of requests, and we can profile the whole
bunch. Our requests vary a lot, with many simple ones and a few *really*
complex ones, so I've used scales on charts that handle the long tail.
As a side note, the Perl in webinject was somewhat hacky non-modern -
I'd love a tool as good as JMeter.

Thinking about it, if you can live with the Java interface, JMeter
rocks. It is great at modelling large sets of users with randomised
request times, and displaying how number of users affects response
latency. For performance, I don't know of anything in the Perl world to
touch it, but I'd love it if something did.

This actually evolved as we work on a problem that is distinctive to our
app under VMware ESX. We use using it to benchmark against VMware
Server, which runs 3-4 times as fast as VMware ESX at the application
level. There are *many* small differences between the two, although the
big hit seems to be MySQL memory access (of all things). Some kind of DB
issue showed up well in NYTProf, but other testing was needed to go
further. Even a tool like NYTProf will not guarantee you can find the
problem, because it may not be in Perl, let alone your app.

--S
--
Stuart Watt
ARM Product Developer
Information Balance


Matija Grabnar wrote:
> Carl Johnstone wrote:
>> NYTProf profile or it didn't happen :-)
>>
> Is there any "best practices" or hints page on how to use Catalyst and
> NYTprof? I haven't used it before and I wonder if people include it
> into a running catalyst application (and then periodically review
> results in some way) or if they include it only into a
> just-for-profiling server which then runs a synthetic load? Or
> something in between?
>
> I've had some problems with a catalyst application lately, but it
> turned out that it was caused by the FCGI servers being swapped out:
> no ammount of tweaking my code would have solved it, all it took was
> an extra $10/month for another 256M RAM.
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>
> --
> This message was scanned by ESVA and is believed to be clean.
> Click here to report this message as spam.
> http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=43BA02807E.D8421
>


pagaltzis at gmx

Apr 29, 2010, 8:02 AM

Post #72 of 72 (4311 views)
Permalink
Re: Alternatives to Catalyst ? [In reply to]

* Oleg Pronin <syber.rus [at] gmail> [2010-04-29 11:10]:
> Maybe it is not the bottleneck, but how many places do we have
> like this that are "not a bottleneck" ? maybe the sum of all
> these "mini" mistakes is the bottleneck ?

Maybe, maybe, maybe. Stop guessing. Profile the code in question.

Here is my experience – *experience*, not theory, and not dogma:

If you look at any non-trivial piece of code, and you guess where
the performance bottleneck in that code will be, you will ALWAYS
be wrong. This is not a figure of speech. I am not taking poetic
licence here. I very literally mean you will guess wrong EACH and
EVERY single time.

Furthermore my experience is that in almost any codebase, the
execution time is spent almost entirely in very few spots. If you
optimise any other part than those spots, even if you make it
500,000 times faster, the result will be virtually nil. You can
even make *every*thing faster, *except* the hotspots, and it will
still add up to almost no improvement.

This is why we don’t all still write assembly today.

(Which is actually a pity, and part of the reason why so much
code today is so slow. Not because the code isn’t written in
assembly, but because it’s not written by assembly programmers.)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

Catalyst users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.