Category Archives: Code

Software Development

Windows Delayed Startup Script

Put this in the Target of a cmd.exe shortcut and optionally set Run to Minimized:

cmd.exe /c “dir ..\StartupDelayedStart\* && Timeout /T 10 && echo ‘waiting…’ && Timeout /T 30 && for %f in ( ..\StartupDelayedStart\* ) do start “” “%f” “

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.