Today, I ventured into #dbix-class inquiring about some performance problems I was having. I wasn’t complaining about the speed of DBIC, I was looking for ways to trim out work that I was doing that I could avoid doing. The script I was running (file parser + insert into DB) was taking a little more than an hour to run. I was musing whether to drop DBIC, parallelize the job or just deal with the slowness when* ribasushi* (Peter Rabbitson) came to the rescue. After sharing with him a copy of NYTProf’s output, he quickly identified some hot-spots in SQL::Abstract that could be worked on. Soon enough, Caelum (Rafael Kitover) chipped in and we had improvements (some XS code wasn’t being used) in Class::Accessor::Grouped coming. Within an hour I was upgrading CAG, SQLA, DBIC and installing Class::XSAccessors and profiling the code again.
Total improvement: time spent inside CAG dropped by 57% and 44% in SQLA
Total time elapsed: ~2 hours.
If this is not a sign of what makes the perl community great, I don’t know what is.
The code is not flying any any means, but the total runtime was reduced by 34%, which is not bad for an evening’s work.
SQL::Abstract Changes
DBIx::Class Changes
(read on for comparison of the top 15 subs)
SawyerX, in his ongoing stream of posts regarding marketing Perl, recently blogged about project websites and suggested we all start hiring, and paying for out of our own pockets, designers to market our free offerings. I kinda wanted to smack him after reading that. I try not to comment on marketing or advocacy, etc. because I really just don’t care. I don’t care if new people use perl or what they think of it. I know it’s good and I know it works. I like my hammer, I think it’s a great hammer, and if you judge by the projects I produce, you would find that to be obvious. However, I will say that even though I consider all this marketing talk to be annoying at best, he does have a point: Our OSS code is our resume. When applying to new jobs, it is easy to list things we did on a resume, but often times we are unable to provide cold hard code to employers because our previous employer owns the rights to it or we are bound by NDAs etc. This puts us in the situation where we often find ourselves saying, “Hey Guy, you should give me a job. I’m a great architect, I’ve built some awesome buildings, many of which you have seen. I just can’t show you them, but trust me, I’m good.” That obviously sucks.
So, while I disagree with the need to throw money at designers to make pretty websites for libraries whose target audience is Perl developers who already know how to work CPAN and probably know how the rest of us roll, it’s be nice to have websites for end-user applications. You know, the kind of stuff people who don’t give a damn about the API use, whether it be from the web or the command line. Those are the people that might not know to look in CPAN / perldoc. Those are the people who don’t care about our API docs, they just want interface docs and frequent use cases illustrated. In this case, it makes perfect sense to have pretty, user-friendly websites published. IMHO, you should also have a PDF manual. But for libraries? give me a break guy. We got better things to do.
Is it just me who has to re-authenticate on every single page load, or is this a known issue? It's really annoying? I seem to keep my session fine on the front page, but the MT interface asks me to authenticate every. single. time. I change pages, whether through a GET or POST request.
Today, Ovid blogged about long-running test-suites and how to optimize them.
Yesterday, I was thinking about this same exact thing. I have a project where the compile-time hit of the collective libraries that make up the application is a little on the heavy side. I thought to myself that it would be good use something like Test::Aggregate, but I wondered if that could mean that some of my tests could be affected by a downstream dependency where the state could be changing at the class level. I don’t think it’s very probable, but it could happen and it would be a real pain to debug.
I just released a new version of Cantella::Worker and I'm really happy with the improvements. I updated Cantella::Worker::Manager::Prefork and added a couple of options to add a little more fine-grained controls to the worker processes, such as whether the workers should detach from the manager's session or not and a way to adjust the priority of worker processes. More importantly, I added the "program name" attribute and functionality and I made children automatically shut down if their manager dies, so that you never have an unsupervised worker pool. Special thanks to Rocco Caputo for his help. So, here's an example so you can see the progress made:
I blog about Perl.