Work on siunitx v3

I recently posted a few ‘notes to myself’ about future directions in siunitx development. With them down in print, I’ve been giving them some serious thought and have made a proper start on work on version 3 of the package. I’m starting where I’m happiest: the unit parser and related code, and am working on proper separation of different parts of the code. That’s not easy work, but I think it should give me a good platform to build on. I’m also working hard to make the new code show ‘best practice’ in LaTeX3 coding: the plan is to have much richer documentation and some test material to go with the new code. Looking forward, that should make creating a ‘pure’ LaTeX3 units module pretty easy: it will be a minor set of edits from what I’m working on now.

I’ve got a good idea of the amount of work I need to do: there are about 17k lines in the current siunitx.dtx, which comes out to around 7.5k lines of code. That sounds like a lot, but as much of what I need to do is more editing that writing from scratch I’m hoping for an alpha build of version 3 some time this summer.

6 thoughts on “Work on siunitx v3

  1. This sounds great and like a sound plan, I am looking forward to the new version.

    Please do not forget the performance of the package while refactoring the code. While I generally agree, that maintainable code is more important than fast code, this is not completely true if there is no optimizing compiler available as it unfortunately is the case with TeX.

    Just as one empirical data point: I keep most of siunitx’s functionality deactivated in my current document and will only activate it directly before submission (and hope, that everything comes out – ok, I could test it from time to time). The reason is, that siunitx needs the largest part of the compilation time (≈30 s with siunitx vs. ≈10 s without siunitx), which seems not appropriate when comparing siunitx’s task with the whole TeX and all the LaTeX packages’ task.

  2. @Stefan Plan is to have some automated tests for the lower level functionality, but I will certainly be after proper human testing! (My idea is that if I get things right, the code will need little change to be used with ‘stand alone’ LaTeX3, and there automated tests are more-or-less a requirement.)

  3. @Patrick I’m aware of the performance question. Much of the ‘hit’ comes from parsing numbers (this can be seen for example in large tables, where switching to the dcolumn-like approach is very much faster than parsing). I’ve got some ideas in mind to alter how things are done behind-the-scenes, but one of my problems is that people want to do a variety of complex things and those require more-or-less complete parsing. I have some ideas on where I might gain some speed, but I need to test those out. At present I’m working on the unit parsing/formatting code, and there I don’t think I can do much in speed terms (I have a few tune-ups but not I suspect a lot of gain). It’s worth remembering that I’ve refactored the number parser before, and it’s a lot faster than the one in v1. (Of course, 30 s for an entire document is actually fast by historical standards for TeX, but selling that to most users today is very hard!)

    Two places I do expect some performance improvements in are font selection and choice of mapping functions. I’m going with a new approach to font selection (more details once the code is ready), and I expect that in the common case of standard math mode output this should be quite a bit faster. On the mappings, working on expl3 I’ve got a good idea about which versions will be quicker, so I’m going to alter some of the internals to reflect this.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.