errors::windows contributes to bloat

[Swatinem]

In a quest to reign in the compiletimes of symbolicator, I was looking at cargo bloat output, and some of the huge error enums in errors::windows are among the top listed functions:

 File  .text     Size                   Crate Name
 0.3%   0.5% 108.8KiB         minidump_common <minidump_common::errors::windows::WinErrorWindows as core::fmt::Debug>::fmt
 0.2%   0.4%  85.7KiB         minidump_common <minidump_common::errors::windows::NtStatusWindows as core::fmt::Debug>::fmt
 0.2%   0.3%  62.0KiB         minidump_common <minidump_common::errors::windows::WinErrorWindows as num_traits::cast::FromPrimitive>::from_u64
 0.1%   0.2%  39.6KiB         minidump_common <minidump_common::errors::windows::NtStatusWindows as num_traits::cast::FromPrimitive>::from_u64

This seems a bit excessive to me. Although admittedly, I’m unsure how much this really means in terms of compile/link times.

Output of cargo llvm-lines shows a generic &T as fmt::Debug as the second worst offender, though its unclear if that is related to errors::windows, as some more specific functions are way lower on that scale:

  Lines                  Copies                Function name
  -----                  ------                -------------
  9852153                271193                (TOTAL)
    73972 (0.8%,  1.5%)    6184 (2.3%,  3.4%)  <&T as core::fmt::Debug>::fmt
     2837 (0.0%, 41.1%)       1 (0.0%, 25.6%)  <minidump_common::errors::windows::NtStatusWindows as core::fmt::Debug>::fmt
     2836 (0.0%, 41.2%)       1 (0.0%, 25.6%)  <minidump_common::errors::windows::NtStatusWindows as num_traits::cast::ToPrimitive>::to_i64
     2836 (0.0%, 41.2%)       1 (0.0%, 25.6%)  <minidump_common::errors::windows::NtStatusWindows as num_traits::cast::ToPrimitive>::to_u64
     2835 (0.0%, 41.2%)       1 (0.0%, 25.6%)  <minidump_common::errors::windows::NtStatusWindows as num_traits::cast::FromPrimitive>::from_i64
     2835 (0.0%, 41.3%)       1 (0.0%, 25.6%)  <minidump_common::errors::windows::NtStatusWindows as num_traits::cast::FromPrimitive>::from_u64
     2832 (0.0%, 41.3%)       1 (0.0%, 25.6%)  <minidump_common::errors::windows::WinErrorWindows as core::fmt::Debug>::fmt
     2831 (0.0%, 41.3%)       1 (0.0%, 25.6%)  <minidump_common::errors::windows::WinErrorWindows as num_traits::cast::ToPrimitive>::to_i64
     2831 (0.0%, 41.3%)       1 (0.0%, 25.6%)  <minidump_common::errors::windows::WinErrorWindows as num_traits::cast::ToPrimitive>::to_u64
     2830 (0.0%, 41.4%)       1 (0.0%, 25.6%)  <minidump_common::errors::windows::WinErrorWindows as num_traits::cast::FromPrimitive>::from_i64
     2830 (0.0%, 41.4%)       1 (0.0%, 25.6%)  <minidump_common::errors::windows::WinErrorWindows as num_traits::cast::FromPrimitive>::from_u64

As these enums are just extremely huge, and there is probably little to do about that, I wonder if it might be possible to reduce the impact of fmt::Debug and from_u64 a bit, maybe by generating a perfect hash table for them instead of having the compiler derive a huge match statement. Although I have no idea if that would even make a difference?

[gabrielesvelto]

errors::windows in enormous and bound to grow with each new version of the Window SDK. We can probably implement the traits by hand in a more efficient way but I wouldn't know how much it would save in terms of compile time.