Deprecating 32-bit perl

I announced recently that for one of my perl modules, Number::Phone, I would be dropping support for 32-bit versions of perl. On the mailing list that I have for users I heard nary a peep, but when I announced it in public groups I got some pushback, so I thought it would be a good idea to explain why I'm doing this, and also why I don't think it's a problem.

So first, why? It's quite simple really. Bundled with Number::Phone is a lot of data. The 25MB (compressed) distribution tarball expands to 123MB, of which 98MB is one single data file. Disk space is cheap this century, so I didn't worry about this for ages, until one of the users asked if I could split that data file out into a separate optional add-on, as it was taking most of the space in his Docker containers, and was a substantial financial cost for him. Splitting it out would require a long deprecation cycle, so as a temporary work-around I have provided a build-time option to leave out that file when you install the module and save disk space in exchange for reduced functionality. But I really want to provide full functionality and save disk space.

The large file is a DBM::Deep database. DBM::Deep is a fantastic tool, it provides an on-disk representation of an arbitrary data structure of arrays, dictionaries and scalars. You can access all the data completely transparently, and it eats hardly any memory. You can even add, edit and delete bits of the structure. An on-disk data structure that requires minimal memory is exactly what I wanted. However, editability comes with costs. In particular it costs lots of disk space. Not only do you have to allow space for data structures to grow (at minimum this requires space for extra pointers to data that would be added at the end of the file), to edit in a reasonable time also means that you have to potentially store the same data a great many times if the same value appears in multiple places.

But I don't need editability. It's enough that I can create a database once, and the users only need to be able to read it. So I created a replacement. Data::CompactReadonly stores in 6.1MB what DBM::Deep needs 98MB for. Database creation is slower and requires more memory than with DBM::Deep, but I don't care about that. Database access for users requires no more memory than DBM::Deep if you accept it being about half the speed, or if you can accept it using a bit of memory it is four times faster than DBM::Deep. And that's an early version, I've put some work into optimisation, but I'm sure I can wring some more performance out.

I didn't want to just write something for use by Number::Phone though, I wanted a general-purpose tool. To be general-purpose it has to support 64-bit values, and because I am lazy the current version requires 64-bit integers. I may find the tuits to get rid of that requirement at some point, but I'm not going to put much effort into that, because ...

... I doubt I have any 32-bit users. Perl has supported 64-bit architectures since at least 2003, and also supports 64-bit integers on many platforms that only have 32-bit pointers. I gave a 2 year deprecation warning, so by the time I release a version that requires 64-bit integers they will have been available on all reasonable platforms and many thoroughly unreasonable ones for just a few months short of twenty years. It hasn't been possible to even buy reasonable server-grade 32-bit hardware for a decade or more and even unreasonable hobbyist servers like the common cheap ARM boxes can run a perl with 64-bit integers.

So there you are, that's why I'm deprecating 32-bit perl, and why I don't think anyone will notice when I stop supporting it.