xcomcmdr wrote on 2025-08-26, 20:18:

And from the 2nd time this app call happens, it has already been compiled natively by the JIT, so it's even faster.
And *then* dynamic PGO kicks in, which optimizes the app over time, making it even faster.

Yeah, modern .NET is amazing, and 4 calls deep in the call stack is nothing compared to I/O delays anyway... 😁

Doing JIT and optimizations at run time are (very elaborate) mitigations for the drawbacks of not having produced native code in the first place. Having to load .NET components from disk is a cause of I/O delays. None of this is really a win from the user perspective.

Nevermind the security implications, and the performance impact, and the fact that strings are *hard* ...

There was a publicized case where a library function for user input validation was sending every string to Google servers. So... yeah.

BTW, if strings are hard, why is there an epidemic of text-based data formats? 😦

bakemono wrote on 2025-08-30, 10:14:

xcomcmdr wrote on 2025-08-26, 20:18:

And from the 2nd time this app call happens, it has already been compiled natively by the JIT, so it's even faster.
And *then* dynamic PGO kicks in, which optimizes the app over time, making it even faster.

Yeah, modern .NET is amazing, and 4 calls deep in the call stack is nothing compared to I/O delays anyway... 😁

Doing JIT and optimizations at run time are (very elaborate) mitigations for the drawbacks of not having produced native code in the first place. Having to load .NET components from disk is a cause of I/O delays. None of this is really a win from the user perspective.

The JIT compilation is done once and then cached.
The standard library is loaded are program startup, just like with a any other program.
By the time of the 'string function' we are talking about is called, there is no I/O.

.NET can be compiled AOT now. Guess what, it only reduces startup time. It does not make your program magically faster.

Because a .NET app was already a compiled program (just compiled into bytecode), and the standard library is already natively compiled.

In fact, since AOT'd code can't benefit from Dynamic PGO, an AOT'd .NET app can be a little bit slower.

bakemono wrote on 2025-08-30, 10:14:

Nevermind the security implications, and the performance impact, and the fact that strings are *hard* ...

BTW, if strings are hard, why is there an epidemic of text-based data formats? 😦

You are comparing apples and oranges.

Using libraries as intended is not really the problem.

String manipulation is part of most language standard libraries. The regex library is also available separately and can be used where needed. Strings are not hard, but we did manage to break it with all these extended character modes and escapes (think about the iconv debacle with the extended chinese character set for example)

The heaviest weighing problem is not libraries, but frameworks instead.

Frameworks are for those who don't want to code themselves and rely on others' concept of what is in vogue. Start stacking these things on top of each other, and you end up with what the modern UI / modern web convergence fuckup essentially is. That's why you need 8GB and plenty o' cpu for a couple of tabs or windows.

.NET is a framework... formerly known as .NET Framework... 😁