As others have mentioned, it's not actually that performant. The matrix solve is about as fast as a single threaded solution can do, but the problem is parallelizable. There are a number of GPU implementations and I have even heard of offloading the matrix solve to an FPGA, though without unified memory a lot of the gains are irrelevant.
Even if you avoid most of the numerical code initially, the interface in the original spice core is a mess of string handling and building a custom shell experience. There are tricks like setting the upper bit of every byte to 1 when inside quotes so that the custom shell history matching skips over things in quotes. Very elegant for the time, but now that means if you want nodes with non ascii names you're either keeping a mapping outside or using utf-7.
Another great example is the expression parsing. There was a long standing bug where the expression parser leaked ~160 bytes for every step of an output expression for every timestep. So for example, if you had "($2 * 4) + 1" as an expression and ran a simulation for 10,000 timesteps you'd leak 8M bytes.
The spice core that ngspice is built off is terrible code. It has a long history going back to 1970s era fortran. Starting fresh is probably preferable
Not to mention, lots of places have time of use electricity pricing which makes it even worse. This is the problem with running my heatpump when its cold, some of the coldest times (right before dawn) coincide with peak time-of-use prices
Even if you avoid most of the numerical code initially, the interface in the original spice core is a mess of string handling and building a custom shell experience. There are tricks like setting the upper bit of every byte to 1 when inside quotes so that the custom shell history matching skips over things in quotes. Very elegant for the time, but now that means if you want nodes with non ascii names you're either keeping a mapping outside or using utf-7.
Another great example is the expression parsing. There was a long standing bug where the expression parser leaked ~160 bytes for every step of an output expression for every timestep. So for example, if you had "($2 * 4) + 1" as an expression and ran a simulation for 10,000 timesteps you'd leak 8M bytes.