Speeding Up Code
The latest heavy project at $work makes me miss C a bit. There's a lot of Moose objects, KiokuDB, MooseX::Getopt (which is evidently much lighter than I thought) and more. To display all the entries I have in a KiokuDB SQLite database, it takes roughly a second and a half!
Profiling with NYTProf 3.0 (FTW!) shows that Moose takes the most. I don't want to use Mouse for various reasons which I won't go into. Moose::Compile, MooseX::Antlers, nothing near production yet (but I'm keepings my fingers crossed). I tried to rewrite the MooseX::Getopt part and use Getopt::Long manually, but it only speed it up by 30ms. Oh, and yes, everything is immutable. Requiring KiokuDB::Navigator only in the part that loads the navigator gained me 300ms.
I can start rewriting everything with clean Perl objects. It could take a while, but I could get it done. However, that would be losing all the fun and power I get from Moose. Instead I thought of a different idea.
Since I want to integrate this with another database backend (which might be on a remote server) anyway, the speed will slow down a lot because even a small request for display the local database entries would make a trip to the remote database, so even without Moose, the penalty would be great.
I thought of putting everything in a daemon, which would compile and load all the code. The client would be simple code which just asks the daemon to run things. The runtime penalty can't be too big, so I think it would work out. The daemon could fetch the remote data once in a while or per command. That's about it.
I might try to rewrite it without Moose and see the differences. That would be interesting to note in the lectures I'll be giving on Moose next week.
Gots to do the bloggingz
PersistentPerl on cpan is definitely worth a look - I use it to drive a heavy Catalyst / DBDx::Class app
Compiler and perl config options (like no threads, if you haven't already) might yield useful gains.
Seems interesting, but:
/usr/lib/perl/5.10/CORE/proto.h:47: note: expected ‘XSINIT_t’ but argument is of type ‘void (*)(void)’
I tried PPerl. It seems last version was in 2004, which sucks. It didn't add any notable speed. :/
Lately I have had a similar problem: I used Moose for a webservice but this results in large response times. But they can be avoided using CGI::Fast
Yeah, you definitely don't want to be running Moose code in a non-persistant environment. Heck, I wouldn't run any code in a non persistant environment these days. The speed differences are just too great.
Also, I think you overestimate the performance hit you're going to take when you use an external database. As long as you have a decent network, you will hardly notice it.
The server you suggest already exists in the form of App::Persistent. http://github.com/jrockway/app-persistent. Moose apps start up as fast as non-Moose apps now, once you've paid the initial cost at boot time (or whatever).
I don't recognise that particular warning, but I do normally need to apply a/some patches from its RT queue before it'll complile - particularly on solaris - it seems to have a memory leak, reducing the effective max number of runs I can set it to.
You won't notice any speed increase on the first run - but you should notice there's no compile-stage hit on subsequent runs.
I run a pretty heavy Catalyst / DBIx::Class / HTML::FormFu application with a normal compile time of about 10 seconds, under vanilla CGI successfully.
It looks like FCGI is under more active development, so I'll probably check that out next time I deploy.
It looks kickass.
I only saw the Devel::REPL example, is there any documentation on how to install, how to work with it?