Gist of the Day: Analyzing Performance with

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”

Gist of the Day: Some convenience macros for use with Perl C internals

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”

Gist of the Day: Inline::C in Perl

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”

Gist of the Day: Automated Testing With CUnit

It’s no secret that I love automated testing. I have done automated testing in Perl, C, Java, JavaScript, C++, Python, Objective-C, and PHP. I have yet to find an automated testing framework I didn’t like. C is a unique case since it requires a little more cleverness to perform some of the normal control techniques that you can do with other frameworks.
Continue reading “Gist of the Day: Automated Testing With CUnit”

Gist of the Day: Roles in Moose!

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 Chicken.
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.

Continue reading “Gist of the Day: Roles in Moose!”

Gist of the Day: Perl require Versus use

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 use and require in Perl?

Continue reading “Gist of the Day: Perl require Versus use”