Faster IndexOf for Substrings in .NET

Sure. I like Linux and OSS. If anything happens that is unexpected I can trace it back to the source code that makes up my programming environment. I actually like C# as a programming language. It's .NET that's effed up. .NET development happens behind clicks and VS interfaces. The resulting configuration ends up in REALLY unreadable XML files, sometimes obfuscated behind object ids even. I like flat-file human-readable configuration. Also, Entity Framework can just curl up in a ball and die somewhere alone and crying. It's the most useless ORM I have ever worked with. And the documentation on it is just plain wrong often. Following a basic example can lead to results different from those advertised in documentation.

This is all born from experience. I was working on a project I believed in and came to it after the stack used was crystallized and unchangeable. I ended up throwing my hands up in disgust and leaving.

WinForms sits on top of classic Win32 UI (HWND etc) architecturally, and that's what constrains its performance more than anything else. The way you get more perf is by taking over and rendering everything yourself, like WPF or WinUI does. But you can't do that while maintaining backwards compatibility - stuff like Control.Handle or IWin32Window.

In .NET 6, there is new "EnableNullable" directive that will do that. It's on by default for new projects.

That is a very valid reason.

> You need to fix every single form and control.

As anecdotal evidence, I certainly did not do this in my migration of several WinForms apps (one large and several small) to .NET 6. They flubbed the default font in .NET 5 so WinForms users had to wait a bit longer, but it's fixed in .NET 6. My forms all work fine in .NET 6 without change. It would have been infeasible to revisit all of the forms.

Do you have specific examples of APIs that changed? I can't think of any. I think changing the WinForms API would have taken a lot more effort than they actually invested to get it running on .NET Core. From where I'm sitting, it seems like they did the minimum necessary to get the existing DLL to run, and then spent 95% of their budget on the out-of-process designer rewrite.

Edit: I thought of one. They removed Menu; now there is only MenuStrip. I did have to make code changes for this and I totally forgot about it. It was minor though; we used MenuStrip anyway, there was just some code with optional support for Menu that I removed.

The designer isn't the runtime. Custom controls work fine in the application; it's the click-and-drag builder in Visual Studio that doesn't work. I don't miss it.

In what concerns the desktop, it has become a mess with the UWP failure, so they are now shoting in all possible directions, unfortunely.

I disagree. Like, you have `StringComparison.Ordinal`, which is case sensitive, and `StringComparison.OrdinalIgnoreCase`, which is indeed case insensitive, but it's a separate thing.

Those things only matter when your strings contain human-oriented text, but that's not the only (and dare I say not even most common) usage of strings. Obviously it's best to be explicit about how you want the contents of your strings to be treated, but absent that, I don't see how defaulting to ordinal string comparison is Anglo-centric. The English culture doesn't use ordinal comparison. Defaulting to ordinal comparison can actually _prevent_ breakage for people using non-English cultures, because strings suddenly behave differently in ways the developer didn't anticipate or test.

(Also, I should've said codeunit-compare instead of byte-compare, since C# strings are always UTF-16 encoded).

.NET strings are backed by two-byte UTF-16 codepoints, not bytes in an unknown encoding.

But ordinal comparison means ignoring equivalence classes, like U+006E (n) + U+0303 (combining tilde) being considered the same as U+00F1 (ñ). But - perhaps more surprisingly - .net's non-ordinal match also matches things like "ß" and "ss".

That leads to some weird things like even if two strings compare as equal in the invariant culture, if you uppercase them in the invariant culture they may no longer be considered equal.

And that's all before you start looking at culture-variant behaviors like different cultures having different casing rules (see Turkish dotless i) or approaches to diacritic equivalence for sorting.

For comparison I’d be happy to force a comparer and never assume anything.

But the problem can also be flipped around and generalized to include formatting. To seem well designed I think it should be symmetric in formatting/parsing wrt what must be provided. In formatting it’s more clear that the system must assume assume format, or some operations become unergonomic (once one wants to be sloppy and allow concatenation of string and int for example). But perhaps one could compromise and just allow ints (assume invariant) but not floats (require formatter).

There's a lot more that doesn't have to do with the JIT. Yes, in some cases it's about providing hints to the JIT to generate better code. Things like casting to unsigned types for example. But the weird ones (one I came across recently was something like condition ? true : false) are fairly rare. Which makes sense in a way: Not all code is that performance-critical that you have to save two instructions. But for things where the baseline performance is a few nanoseconds in many cases, it probably makes sense taking whatever measures you can to ensure that the machine code looks like you'd expect (and make a note to improve the JIT, which also happens regularly).

Technically you could count vectorization in the category of codegen issues, but since the JIT won't output vector instructions on its own I don't think that's really fair (and you have the same issues in languages like C or C++ that do auto-vectorize, but not reliably or good enough).

What is also frequently optimized, is allocation behavior by ensuring that the code doesn't allocate more memory than needed and in a lot of cases no memory at all. And C# has a lot of tools for that kind of optimization that don't really veer into code that looks atypical.

Certainly, but I don’t think it’s unreasonable of them to assume a prior basic knowledge of GitHub.

The releases page is the prebuilt binaries they publish, and there are several links you can click to view the source at the tag, commit or main-branch level.

Their site broke recently. Before it had nice benchmarks included. Apparently string backend researchers are not that good in maintaining website frontends.

That is the instruction for multiplying just one double (the SD suffix stands for scalar double); the respective instructions for handling more than one number at the same time have a PD suffix (for packed double).

The alternative would be to use the x87 FPU registers and instructions, which are a lot slower these days (but yes, also with different precision characteristics). So they're usually not used at all in code targeting x64.

Technically, that instruction is a scalar one. It multiplies just one number in the lowest lane of the vectors, and copies the second lane from the first vector register without changing it. BTW, on modern processors, the performance of such scalar instructions is exactly the same as their vector equivalents which handle all lanes of the registers.

Before AMD64 took off, that C++ code compiled into x87 instructions https://en.wikipedia.org/wiki/X87 That thing is ancient with first implementation from 1980, and some architectural features make it borderline impossible to be performant. For instance, internally it operates on 80-bit floats. Both FP64 and FP32 IEEE floats are being emulated based on bits in the control register.