In my post on
Inline::C a few days ago I mentioned The Rules of Optimization Club, and then I ranted a little bit about how if you cannot measure a performance problem then you don’t have a performance problem. That’s not to say that you’re incorrect in asserting that you have a performance problem, it is only to say that you cannot identify any particular part of the problem as a performance problem until you have measured it.
There a great number of ways to measure performance problems, profiling probably being the most useful in situations involving large applications where you want to test performance under real-life situations. For profiling, I would recommend you look at
Devel::NYTProf. This profiler is exceptionally feature-rich and has a boatload of useful functionality. All that said, here I’m only going to talk about bench-marking small pieces of code. Continue reading “Gist of the Day: Analyzing Performance with Benchmark.pm”
I feel awful. Like, really awful. The baby is sick, my partner is sick, I am sick. You still want something neat though, so I’m going to show you something very simple that I’ve used for a while.
As I’m sure you noticed in yesterday’s
Inline::C demo, Perl guts and C API are pretty noisy with a lot of boiler-plate. For this reason, when I first started playing with Perl guts and API, I created a header file just to make things a little simpler. Nothing here is terribly complicated, and they’re all just simple convenience macros, but sometimes that type of macro saves you oodles of time. Continue reading “Gist of the Day: Some convenience macros for use with Perl C internals”
I like Perl and I like C (most of the time), and sometimes I like to mix the two. The two main reasons I might want to mix the two is for performance, or because something is written in C which I would like to use from Perl. I’ve only really ever used C from Perl, I’ve never used Perl from C. Today’s demonstration is how to implement a simple binary search algorithm in C, but using Perl internals, and calling the algorithm from Perl. Continue reading “Gist of the Day: Inline::C in Perl”
Continue reading “Gist of the Day: Automated Testing With CUnit”
Have you ever struggled with how to structure your class hierarchy, given a common type of functionality which applies to some classes but not others? Say for instance you have a class named
Animal. With this
Animal class you can derive all of your animal classes. Take for instance a chicken, for which you subclass
Animal to a class you call
One of the features you’d like to implement is that an animal makes a noise. Chickens, for instance, cluck. Some animals, however, don’t make a noise. Take a seahorse for instance, it doesn’t make noise. It is every bit an animal, but it doesn’t make noise. There are many other mute animals across many different families of animals, so it doesn’t really seem to fit in to your hierarchy. For this purpose, you can use a Role in Moose. A role allows you to dynamically add functionality to an existing Moose class (as many of them as you like) without having to mangle your nice, clean class hierarchy. Think of it as a grab-bag of functionality for your class which can also be used by other classes regardless of their parentage.
So, way back when I used to be a guy who thought up interview questions for super-senior Perl developers. I actually developed quite the reputation for being a very effective first-round interview for senior Perlers. My interviews were perceived to be so tough that headhunters would debrief the candidates so they could create cheat-sheets. I never considered my interviews very difficult at all. Despite the fact that very few of the candidates passed my first round, none of these questions seemed very difficult to me. Mind you, the client I was interviewing for wasn’t looking for someone who was a good programmer, they were specifically looking for a good Perler (a very good Perler). It is important for interviewers to ask questions relevant to the job they are hiring for, and if you have a legacy application which is using a lot of the in-depth features of a language then that language may become something very important to your hiring.
This is one of those “gotcha” questions that I actually had a recruiter try to call BS on me with, and I think it’s a fundamental one since it really reflects whether or not you understand how modules work in Perl:
What is the difference between
require in Perl?
Continue reading “Gist of the Day: Perl require Versus use”