Clojurians Log v2
clr 2026-10-08
I've been doing some benchmarking looking for places where performance can be improved.
One area that I've looked at is in string handling, specifically string comparisons.
ClojureCLR differs from ClojureJVM in that java.lang.String.compareTo is ordinal-based, while System.String.CompareTo is culture-sensitive.
I viewed this (a long time ago) as just exposing the underlying platform. But it had consequences I didn't understand at the time.
The performance difference is non-trivial. Making a switch to ordinal-based would be a breaking change on several levels, and we do try to avoid that.
However, I'm looking at a way to make the option (ordinal vs culture-sensitive) settable at ClojureCLR startup, based on an environment variable, so that users could choose.
I've written about it (of course) here: https://dmiller.github.io/clojure-clr-next/general/2026/10/07/stringulation.html , should you be interested in the details.
The question of the day: what should the default setting of the switch be for future ClojureCLR releases?
I guess it depends on who you view as the primary audience for ClojureCLR?
• Is it folks familiar with how String behaves in C# and F# but want to use Clojure in that environment?
• Is it folks familiar with how String behaves in Clojure on the JVM, wanting to use Clojure on .NET for whatever reason?
And, if it is the former, are the "native" .NET folks aware of this and the performance overhead?
In Java, you can opt-in to locale-aware collation etc. I don't know what the equivalent is in C#/F#.
To me it seems fine to default to the fast option, but I don't have any serious ClojureCLR projects yet. By the way, this is only somewhat related, but putting it here in case you hadn't seen it: https://github.com/dotnet/runtime/blob/main/docs/design/features/globalization-invariant-mode.md Another consideration is what F# does: looks like a case-sensitive ordinal comparison for things like sets.
I think the primary audience leans more to C#/F#-familiar people who know their way around .NET already. If they've thought about these issues at all, they should understand the ways of dealing with culture-sensitivity. There are equivalents to locale-aware collation. I was a bit surprised by the magnitude of difference in performance. Not that I had put much thought into it prior to this. Perf and divergence are issues for me, hence the investment of effort. @isak: I had not been aware of globalization invariant mode prior to this little investigation. I think maybe it is more extreme than required.