What's the usual practice about type stability testing in packages?

General Usage
, , ,
1

Julia developers have utilities to test type stability in their packages, as commented in another post long ago. And new tools that improve it have been released since then, e.g. Cthulhu.jl, or JETTests.jl more recently.

However, I wonder to what extent those tools are used in package testing. Creating and maintaining such tests is an extra burden, so perhaps the majority of developers live happy without them, and they are mostly used in packages where performance is critical.

On the other hand, since type stability is a problem that propagates, developers who are concerned about it would like to know that the functions of the packages they depend are type-stable too. So I imagine that popular packages that are widely also take care about it.

But is this only guessing. Does anyone have more informed knowledge about this question?

And could type stability be a separate test target? I fancy about a work flow that would grant badges to signal that the package is tested for type stability. (Although I have no idea about how that might be done.)

1 Like
2

For testing if the return value of a function is type stable, the @inferred macro is helpful.

If you are not concerned about the return type, but rather what is going on inside the function with regards to type stability, I am not sure if testing is the right place to check for type stability. If performance is an important issue that might be affected by type stability, the type stability should already be checked during development. If your concern is, that some modifications/updates might create type instabilities inside of functions, then I would rather test for performance regression as it this is the end goal after all.

2 Likes
3

It would be nice still if we had something like @code_warntype but that would return true or false in the presence of “red lines” inside the function.

2 Likes