Home/ Questions/Q 224739
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T19:20:43+00:00

I am writing algorithms that work on series of numeric data, where sometimes, a

  • 0

I am writing algorithms that work on series of numeric data, where sometimes, a value in the series needs to be null. However, because this application is performance critical, I have avoided the use of nullable types. I have perf tested the algorithms to specifically compare the performance of using nullable types vs non-nullable types, and in the best case scenario nullable types are 2x slower, but often far worse.

The data type most often used is double, and currently the chosen alternative to null is double.NaN. However I understand this is not the exact intended usage for the NaN value, so am unsure whether there are any issues with this I cannot foresee and what the best practise would be.

I am interested in finding out what the best null alternatives are for the following data types in particular: double/float, decimal, DateTime, int/long (although others are more than welcome)

Edit: I think I need to clarify my requirements about performance. Gigs of numerical data are processed through these algorithms at a time which takes several hours. Therefore, although the difference between eg 10ms or 20ms is usually insignificant, in this scenario it really does makes a significant impact to the time taken.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well, if you’ve ruled out Nullable<T>, you are left with domain values – i.e. a magic number that you treat as null. While this isn’t ideal, it isn’t uncommon either – for example, a lot of the main framework code treats DateTime.MinValue the same as null. This at least moves the damage far away from common values…

    edit to highlight only where no NaN

    So where there is no NaN, maybe use .MinValue – but just remember what evils happen if you accidentally use that same value meaning the same number…

    Obviously for unsigned data you’ll need .MaxValue (avoid zero!!!).

    Personally, I’d try to use Nullable<T> as expressing my intent more safely… there may be ways to optimise your Nullable<T> code, perhaps. And also – by the time you’ve checked for the magic number in all the places you need to, perhaps it won’t be much faster than Nullable<T>?

    • 0