-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moo conversion #140
base: master
Are you sure you want to change the base?
Moo conversion #140
Conversation
Moo is now included in one of the test files.
some more work on Moo
All tests are passing
There are some failing tests... |
We are good now. Thanks @tokuhirom and @yanick |
Benchmark(Moo vs Mouse)I benchmark Moo version and Mouse version. Benchmark scripts are in benchmark directory. Environment
cascade.plMoo
Mouse
data_section.plMoo
Mouse
demo-mt.plMoo
Mouse
demo-tt.plMoo
Mouse
expr.plMoo
Mouse
expr_eq.elMoo
Mouse
foo.plMoo
Mouse
include.plMoo
Mouse
interpolate.plMoo
Mouse
json.plMoo
Mouse
x-poor-env.plMoo
Mouse
x-rich-env.plMoo
Mouse
FinallyAlmost case, Mouse version got good result than Moo version. |
Any plans to release this code? |
As syohex showed, Mouse performs better in most benchmarks. |
@itcharlie would it be possible for you to rebase this PR against the latest master (and possibly squash some of those merge commits down)? I think some of the performance differences can be improved. It would be a shame for this work not to be merged, as Moo is preferred over Mouse these days. |
@@ -212,12 +213,14 @@ sub getopt_spec { @Spec } | |||
sub _build_getopt_spec { | |||
my($self) = @_; | |||
|
|||
$DB::single = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line should be removed.
@karenetheridge @itcharlie I can do the rebase, if you want. Shouldn't be too hard. |
Thanks Yanick, @karenetheridge I don't think I will be able to sit down and work on this best, Charlie Charlie Gonzalez On Fri, Dec 4, 2015 at 2:08 PM, Yanick Champoux [email protected]
|
+1 for this changeset. Xslate is the only thing I routinely use that is dependent on Mouse and it would be extremely disappointing to see this work not accepted, especially given that the benchmark differences are pretty negligible. |
@@ -212,12 +213,14 @@ sub getopt_spec { @Spec } | |||
sub _build_getopt_spec { | |||
my($self) = @_; | |||
|
|||
$DB::single = 1; | |||
|
|||
my @spec; | |||
foreach my $attr($self->meta->get_all_attributes) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aha, this would be a contributor to the slowdown -- this Moo class is being upgraded to Moose to get the list of attributes. (thanks @shadowcat_mst)
Rebase to master at https://github.com/yanick/p5-Text-Xslate/tree/moo_conversion I also spotted that the tests are still using Mouse. I'm going to take care of that in the next few hours |
Symbol.pm was a heavy user, solved via
I can only get a 1% benchmark difference because almost all the work in almost all the benchmarks is being done by ->render's XS code. Well, except for the poor-env test where Moo appears to be loading slightly faster but I'm not sure that's really a significant difference either. The getopt stuff in Runner needs tweaking as well but that didn't show up at the top of my profile (MooX::Options would maybe solve this, or borrowing part of its implementation) |
If somebody can propose a benchmark that shows a more-than-1% slowdown in a way I can actually proile, I wouldn't mind poking this with a stick. The Symbol thing was basically the only thing I managed to get a handle on from the benchmark scripts. It's friday evening though, so I may just be being stupid. |
Switched types to be 'Types::Standard' in my branch, which should also speed up the Moo version. |
-1 with this. Just because people can't stand to add one standalone module to their module list, they are willing to impose several new modules to others. @gfx already expressed that he was not willing to switch to Moo but would consider plain objects. Text::Xslate works fine with Mouse, and it doesn't need to be "fixed" with Moo. Personally, I don't want to add Moo and its dependencies to my module set. Already did, and it cost me a week to revert because people knew better than me how I should handle warnings. Not anymore! |
@GeJ If you don't want to write warning clean code, Moo 2.0 in March no longer fatalises warnings by default. If you'd like to learn how, strictures 2 now only fatalises warnings we can be reasonably sure won't cause forward compatibility issues. Also, if you have a pre-2.0 Moo you can easily do -
or use Moo::Lax or ... Plenty of options other than reversion and they're all basically a single perl -pi -e away :) |
@shadowcat-mst I perfectly know that. That's the quick fix I implemented two years ago when I was asked to leave a Sunday family gathering by a pissed off boss who got harassed by an angry client who was asking why none of his orders were processed in a timely fashion. When I went to the office on that day I realized that someone, somewhere thought that appending an undefined value to a string was such an offense to the programming Gods that it should warrant killing any piece of code that would attempt to do so. And that's my problem with Moo : I don't like such clear POLA violations and I can't trust people who commit them. And rather than doing a rollback, Moo users had to use a workaround for roughly a year. Also, and aside any personal opinion I may have on Moo, the root of this PR is just for convenience. There is no technical merit in this. s/Mouse/Moo/g everywhere in the code is not enough, it is slower than the original. Looking back at the PR, it has been suggested to add even more extra modules to catch up, or worse : drop the Moo API and directly tap into the guts of the object to speed up things. Wow! I will repeat myself : just because people don't want to add one standalone module, they are willing to impose their convoluted solution to others. Mouse works just fine. It may not have all the bells and whistles of Moose or Moo, but it is in my opinion the perfect example of a much simple solution that fits the needs of a given problem. If memory serves, when I removed every reference to Moo in my code, there were no Moo-only feature I used that couldn't be replaced by either a Mouse extension or half a dozen lines of code. Finally, a careful reader might remember that a respected member of the Perl community qualified Mouse as "amazing code", adding "If you're going to use Mouse, use Mouse." So, can we please leave it like that and stop trying to fix a problem that doesn't exist. Edit: added a few edits this and there to fix a few mistakes. Please forgive my possibly awful English as it is not my native language. |
+1 for Moo. Because Moo is more widely used and benchmark shows, that is is not slower that Mouse (several percents are standard error). |
It was already clearly documented. I'm sorry you missed it.
The first ever release of Moo fatalized warnings. The delay was to try and minimise the damage to downstream users who -liked- them and regarded them as an important part of their code's integrity. Your "rollback" would've been their "sudden backcompat breakage", and that wasn't acceptable to us. |
Will this get merged and released? |
I turned my own copy of this branch as a PR, considering it's freshly rebased and contain a few extra tweaks (as per the comments above) |
Mouse to Moo conversion changes for issue #94. Thanks to Yanick for the orientation and help.