Die Geschwindigkeit einer executable kann man unterteilen in Load-Speed, also die Zeit die der NT-Imageloader braucht vom starten des programms bis der main-thread den Program Entry Point durchläuft, und Run-Speed, also die Zeit die ein Programm für Aufgabe X braucht.
Load-Speed hängt von der Assemblygröße ab, allerdings zählt nicht 'jedes byte' - sondern nur 4KiB Blöcke - soviel liest der NTImageLoader pro Aufruf von der Festplatte, d.h. ob eine Assembly 10KiB oder 11.9999KiB groß ist macht im Load-Speed keinen unterschied.
Nach dem NTImageLoader kommt bei .Net dann noch der RunTimeCompiler, der compiled line per line, im Falle von .Net spielt hier nun die Assemblygröße eine 'kleine' Rolle, da die gesamte Assembly in einem Satz compiled wird, im gegensatz zum Java-Just-in-Time compiler. Der .Net RunTimeCompiler ist aber um ein tausendfaches schneller als der NTImageLoader, ist i.d.R. schon fertig bevor der NTImageloader den letzten 4KiB Block in den Speicher geladen hat, denn die letzten paar 4KiB Blöcke sind i.d.R. resourcen die nicht compiled werden müssen.
Daher kann man behaupten, dass die Assemblygröße, wenn es um 1000 oder 5000 Zeilen Code mehr oder weniger geht, keine Rolle bei der Geschwindigkeit spielt. Wenn man Pech hat überschreitet man die 4KiB Block größe und dann braucht der ImageLoader eben einen Cycle länger.
Interessanter ist die Runtime-Geschwindigkeit, die meisten Obfuscator bauen sinnlose Jumps überall ein, dadurch muss die CPU bei der Ausführung dauernd die InstructionPipe flushen was die Performance ganz schön drückt, und das ist dann ein viel viel größerer Performanceverlust als den Cycle den der NTImageLoader ggf. mehr brauchen könnte.