Asides

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.

chuser(1) – man page

chuser(1) - man page

Name

chuser- change the current user

Synopsis

chuser [options]

Options

  -n, --now       immediately terminate this user.

  -s, --soft      if painless termination protocols are available,
                  use them. This option is ignored on systems without
                  appropriate hardware.

  -R, --recursive terminate users recursively. This option causes
                  chuser to spawn new chuser processes repeatedly
                  until a user capable of terminating it does so.

  -v, --verbose   replace the usual output of chuser with the
                  input from the microphone.

History

chuser is intended for users who are instructed to use it by 
remote helpdesk operators. It is scheduled for depre-
cation when IT customer services are replaced by robots
with infinite patience.

Comments

chuser attempts to detach the current user from the current
machine. The result of running chuser is non-deterministic
and depends on available hardware. chuser typically fails when run 
by a user who intended to run it, but may succeed when used 
unwittingly. 

chuser expects to run on a foreground thread, so attempting
to background it or run it in a terminal controlled by screen(1)
or tmux(1) may increase the chance of success.

See also

shutdown(8) 
kill(1)
sudo rm -Rf /