Tag Archives: .net

Your CPU vs your code. Two short lessons in software performance

There’s a great Q and Answer at dijkstra-path-finding-in-c-is-15x-slower-than-c-version which starts with C++ code at 2ms vs C# at 38ms; and finishes with C# at 2.8ms.

On similar lines, the solution to this riddle — why-does-net-core-2-0-perform-worse-than-net-framework-4-6-1 — has nothing to do with the framework; it results from the slower performance of 64bit code compared to 32bit.

Which just goes to confirm what you might have suspected;

VMs aren’t that slow; and
For best performance, you have to understand your VM, and your language, and your O/S, and ultimately your CPU.

PowerShell String.Split() Off-by-Method-Overload Error

This seemed to me an error and I and was on the point of raising it as a bug on the Powershell github repo:

PS> "\this".Split( [char]'\', [StringSplitOptions]::RemoveEmptyEntries).Length
# >> 2

Presumably it is because [StringSplitOptions]::RemoveEmptyEntries is coerced to a [char] and so the line is parsed as:

PS> "\this".Split( ([char]'\', [StringSplitOptions]::RemoveEmptyEntries) ).Length

Instead of as

PS> \this".Split( (,[char]'\'), [StringSplitOptions]::RemoveEmptyEntries).Length

If the first parameter is a string not a character then it works as expected:

PS> "\this".Split( '\', [StringSplitOptions]::RemoveEmptyEntries).Length
# >> 1

But the really unfortunate case is :

PS> "\this".Split( [System.IO.Path]::DirectorySeparatorChar, [StringSplitOptions]::RemoveEmptyEntries).Length
# >> 2

which results in

PS> "\this".Split( [System.IO.Path]::DirectorySeparatorChar, [StringSplitOptions]::RemoveEmptyEntries).[0]
# >> $null
# instead of
# >> "this"

It turns out that it’s fixed in Powershell 6 Beta; or to be more precise, it doesn’t happen in PowerShell 6. What changed is that the underlying .Net framework has added new overloads to String.Split():

string[] Split(char separator, System.StringSplitOptions options)                                                                                    
string[] Split(char separator, int count, System.StringSplitOptions options)                                                                         
string[] Split(string separator, System.StringSplitOptions options)                                                                                  
string[] Split(string separator, int count, System.StringSplitOptions options)                                                                       

Whereas PowerShell 5 only has these overloads available:

string[] Split(Params char[] separator)                                                                                                              
string[] Split(char[] separator, int count)                                                                                                          
string[] Split(char[] separator, System.StringSplitOptions options)                                                                                  
string[] Split(char[] separator, int count, System.StringSplitOptions options)                                                                       
string[] Split(string[] separator, System.StringSplitOptions options)                                                                                
string[] Split(string[] separator, int count, System.StringSplitOptions options)                                                                     

And so the best-match overload that PowerShell 6 chooses is different to PowerShell 5’s best match.

IIS Express GUI

Looking for a admin GUI so I can start/stop IISExpress websites I quickly found iisexpressgui on codeplex/ which is by Matteo Tontini and iis express manager. They both do pretty much the same thing. They also both only pick up only the first binding for a site, so if you’ve got two — for instance one for http and one for https — then you might need to edit your %Documents%\IISExpress\config\applicationhost.config to choose the one you want to use.

Mono MVC System.UnauthorizedAccessException Access to the path “/Library/Frameworks/Mono.framework/Versions/…/etc/mono/registry” is denied

Is an error you are likely to see if you run a Visual Studio MVC template in Mono. There are two options for fixing it.

  • Do this from the command line:
    sudo mkdir /Library/Frameworks/Mono.framework/Versions/3.2.5/etc/mono/registry
    sudo chmod g+rwx /Library/Frameworks/Mono.framework/Versions/3.2.5/etc/mono/registry

    (replacing 3.2.5 with your mono version, which you get at the command line with mono --version)

  • Or delete the reference to Microsoft.Web.Infrastructure.dll from the project and delete it from the bin directory too.

The important difference is that deleting Microsoft.Web.Infrastructure.dll will stop your project working on .Net, so the registry access is simpler for cross-platformers. Another option for cross-platform project files would be something like this in the .csproj file:

<Target Name="AfterBuild">
    <Delete Files="$(WebProjectOutputDir)\bin\Microsoft.Web.Infrastructure.dll" Condition=" '$(OS)' != 'Windows_NT'" />
  </Target>

I prefer the ‘grant access to the registry approach’ myself but it does mean having to re-run the 2 line script for every new version of mono.