Re: [Catalyst] Alternatives to Catalyst ?
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 Андрей П. Ковбович akovbov...@gmail.com:
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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ 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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
J. Shirley ha scritto:
On Tue, Apr 27, 2010 at 2:39 AM, Oleg Pronin syber@gmail.com 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
But the question arises: is he the _real_ Oleg Pronin... ?
--
Marcello Romani
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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.ukhttp://shadowcat.co.uk/blog/matt-s-trout/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
2010/4/27 J. Shirley jshir...@gmail.com:
On Mon, Apr 26, 2010 at 1:51 PM, Zbigniew Lukasiak zzb...@gmail.com wrote:
On Mon, Apr 26, 2010 at 1:26 PM, Ben van Staveren
benvanstave...@gmail.com 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On 27 April 2010 12:09, Carl Johnstone catal...@fadetoblack.me.uk 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Tue, Apr 27, 2010 at 2:39 AM, Oleg Pronin syber@gmail.com 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
Good morning,
On 27/04/10 at 1:22 PM +0100, Dermot paik...@googlemail.com 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 ♊ garri...@zeta.org.au
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
〠 http://www.ietf.org/rfc/rfc1855.txt
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On 21 April 2010 18:01, J. Shirley jshir...@gmail.com 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Mon, Apr 26, 2010 at 09:36, Dermot paik...@googlemail.com wrote:
On 21 April 2010 18:01, J. Shirley jshir...@gmail.com 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
From: Ævar Arnfjörð Bjarmason ava...@gmail.com
...
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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Mon, Apr 26, 2010 at 10:57 AM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
On Mon, Apr 26, 2010 at 09:36, Dermot paik...@googlemail.com wrote:
On 21 April 2010 18:01, J. Shirley jshir...@gmail.com 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On 26 April 2010 11:22, Zbigniew Lukasiak zzb...@gmail.com wrote:
On Mon, Apr 26, 2010 at 10:57 AM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
On Mon, Apr 26, 2010 at 09:36, Dermot paik...@googlemail.com wrote:
On 21 April 2010 18:01, J. Shirley jshir...@gmail.com 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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: benvanstave...@gmail.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
- Original Message From: Dermot paik...@googlemail.com 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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On 26 April 2010 12:02, Ovid publiustemp-catal...@yahoo.com wrote:
- Original Message
From: Dermot paik...@googlemail.com
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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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: benvanstave...@gmail.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
(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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Mon, Apr 26, 2010 at 3:48 PM, Wade Stuart w...@grepit.net 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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Mon, Apr 26, 2010 at 12:48, Wade Stuart w...@grepit.net 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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Mon, Apr 26, 2010 at 1:26 PM, Ben van Staveren
benvanstave...@gmail.com 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Ben van Staveren phone: +62 81 70777529 email: benvanstave...@gmail.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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: benvanstave...@gmail.com
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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 Moose-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 jshir...@gmail.com:
On Wed, Apr 21, 2010 at 9:30 AM, Oleg Pronin syber@gmail.com 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Fri, Apr 23, 2010 at 12:36 PM, Oleg Pronin syber@gmail.com 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 Moose-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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Fri, Apr 23, 2010 at 4:36 AM, Oleg Pronin syber@gmail.com 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 Moose-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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Fri, Apr 23, 2010 at 8:36 AM, Oleg Pronin syber@gmail.com 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 Moose-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 Monkeyhttp://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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
Perfomance optimization are unavailable for you because only people like you write such mega slow fuckin code. goodbye 2010/4/23 J. Shirley jshir...@gmail.com: On Fri, Apr 23, 2010 at 4:36 AM, Oleg Pronin syber@gmail.com 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 Moose-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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Fri, Apr 23, 2010 at 8:52 AM, Oleg Pronin syber@gmail.com 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. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On 23 April 2010 16:51, Kee Hinckley naz...@somewhere.com 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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Fri, Apr 23, 2010 at 11:11 AM, Philip Potter philip.g.pot...@gmail.com 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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Fri, Apr 23, 2010 at 5:51 PM, Kee Hinckley naz...@somewhere.com 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 RasmussenConsult::Perl ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Fri, Apr 23, 2010 at 10:27 AM, Lyle webmas...@cosmicperl.com 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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Fri, Apr 23, 2010 at 1:35 PM, J. Shirley jshir...@gmail.com 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 • j...@jmac.org • @JmacDotOrg ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Apr 23, 2010, at 12:58 PM, Lars Balker Rasmussen wrote: On Fri, Apr 23, 2010 at 5:51 PM, Kee Hinckley naz...@somewhere.com 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@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
I do not say that using hashes are good. But i'm sure that developers MUST NOT use super-slow frameworks like Moose-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: benvanstave...@gmail.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Apr 21, 2010, at 1:27 PM, Larry Leszczynski
lar...@emailplus.org wrote:
On Wed, 21 Apr 2010 20:30 +0400, Oleg Pronin syber@gmail.com
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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Alternatives to Catalyst ?
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@gmail.com]
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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Protected by Websense Hosted Email Security -- www.websense.com
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Wed, Apr 21, 2010 at 9:30 AM, Oleg Pronin syber@gmail.com 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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Wed, 21 Apr 2010 20:30 +0400, Oleg Pronin syber@gmail.com
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@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Alternatives to Catalyst ?
On Wed, 21 Apr 2010 20:30:03 +0400 Oleg Pronin syber@gmail.com 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: n...@nickandperla.net http://search.cpan.org/~nperez/ http://github.com/nperez ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
