Dotnet default stack size

Today I Learned that the default stack size for threads in dotnet e.g. the ThreadPool threads is OS dependent. On Windows it is 1.5 MiB, on Linux, MacOs it is dependent on the concrete OS version. To determine the actual default thread size you have to run ulimit -s. For Ubuntu 22.04 it is 8192 bytes and for macOS 14.2 it is 8176 bytes. It is possible to configure the default stack size via environment variable e.

Zeit-Trennzeichen bei DateTime

Diese Woche hat es das .NET geschafft mich zu überraschen, ein Programm ist beim Kunden mit italienischen Windows immer wieder abgestürzt. Nach langem Suchen hat ein Kollege das Problem erkannt, was durch das folgende Beispiel veranschaulicht wird: var ci = new CultureInfo("it-IT"); var dateTime = DateTime.Now; var str = dateTime.ToString("dd.mm.yyyy hh:mm:ss", ci); Console.WriteLine(str); Ausgabe (.NET 3.5): 14.07.2016 20.45.30 Ausgabe (.NET 4.0): 14.07.2016 20:45:30 In der Ausgabe erkennt man, dass abhängig von der .

Performance Vortrag aus 2015

Letztes Jahr habe ich einen Vortrag zum Thema Performance gehalten, der Vermitteln sollte warum dieses Thema jeden (.NET-)Entwickler betrifft. Nachdem ich mir jetzt die Zeit genommen habe um auch die Sprechernotizen aka “Tonspur” auf zuschreiben, konnte ich den Vortrag online stellen: https://github.com/koepalex/performance_talk_2015 Vielleicht ist der Vortrag für jemanden Hilfreich :)

AutoHotkey

Durch Scott Hanselman’s Blog Artikel 2014 Ultimate Developer and Power Users Tool List for Windows. bin ich auf AutoHotkey aufmerksam geworden. Es biete wie AppleScript unter Mac OS X, die Möglichkeit verschiedene (lästige) Aufgaben zu automatisieren bzw. Programme um Funktionalitäten zu erweitern. Damit könnte man zum Beispiel einen beliebiges Programm mit einer Eingabemaske um Snippets erweitern. Als Besonderheit können AutoHotkey-Skript auch in eine ausführbare Datei kompiliert werden und somit auf Rechnern ohne AutoHotkey verwendet werden.

Debugging von Performance Problemen in .NET

Die Analyse von Speicherproblemen ist eine Aufgabe die bei großen .NET Anwendungen häufiger vorkommt. In C++ wurde gesucht, wer welche Speicherblöcke angefordert und nicht wieder freigegeben hat und im .NET Umfeld wird eben gesucht warum der Gabarge-Collector den Speicher nicht freigeben kann. Oder man sucht warum einige Benutzeraktionen besonders lange benötigen. Für die Analyse gibt es eine ganze Reihe guter kommerzieller Programme, auf diese möchte ich jedoch nicht eingehen, sondern ein paar kostenlosen Alternativen vorstellen.

Neues vom GC in .NET 4.0 und 4.5

Heute möchte ich etwas über Erneuerungen im .NET 4.0 / 4.5 sprechen. Das genannte bezieht sich auf den Workstation Garbage-Collector. Die Informationen für den Server Garbage-Collector entnehmen sie bitte den Links. Beginnen wir jedoch zunächst mit einer kurzen Auffrischung. Wiederholung Das .NET Framework unterteilt seinen Heap in verschiedene Generationen. In der Gen0 werden fast alle Objekte erstellt. Die Anfangsgröße beträgt rund 256KB. In der Gen1 werden Objekte gespeichert die eine Garbage-Collection überlebt haben.

GetHashCode dein Freund und Sorgenkind

Eine wichtige Methode beim Arbeiten im .NET Umfeld ist GetHashCode. Sie gibt einen 32 Bit Integer zurück der das Objekt identifizieren soll. Der Hash-Code beschreibt also die Identität des Objektes (im Gegensatz zur Speicherreferenz auf das Objekt). Daraus leitet sich die Frage ab Wann zwei Objekte die selbe Identität besitzen? Im Falle einer Object-Relational-Mapper Klasse beispielsweise, wenn die Instanzen der O/R-Mapper Klasse auf ein und die selbe Zeile(n) der selben Tabelle(n) der selben Datenbank(en) verweisen.

Muss es immer die 100% Lösung sein?

Ich behaupte einfach mal, dass man sich in der Softwareentwicklung schnell in zu aufwendigen Lösungen verliert. Zumindest mir geht es regelmäßig so, ich habe einiges an Software entwickelt und Artikel geschrieben die nie veröffentlicht wurden (obwohl sie dafür gedacht waren). Der Grund für die nicht Veröffentlichung war, dass sie meiner Meinung nach nicht komplett waren oder meinen eigenen Ansprüchen nicht genügten. Das soll nicht bedeutet das die Artikel zu schreiben oder die Software zu entwickeln Zeitverschwendung war.

Pipe aus eigenen Programmen nutzen

Mittels der von Unix Systemen bekannten Pipe (|) ist es auch unter Windows (via CMD-Line) möglich einzelne Kommandos zu verbinden. Die Pipe ermöglicht es die Ausgabe vom dem vorherigen Kommando direkt als Input des aktuellen Kommandos zu verwenden. Beispielsweise den Inhalt einer Datei einem Skript zu übergeben: type input.md | perl Markdown.pl > output.html Logisch gesehen Ersetzt der Inhalt der Pipe ein einzelnes Konsolen-Argument. Um diese Funktionalität auch in den eigenen (Konsolen-) Programme verwenden zu können, sind im Allgemeinen nur zwei Erweiterungen notwendig.

Eindruck und Gedanken zu Mac OS X

Durch den Wunsch ein neues Notebook zu kaufen, stand ich vor der Wahl Linux, Windows oder Mac OS X. Da ich auf Arbeit Windows einsetze und früher in meiner Freizeit viel mit Linux (Ubuntu, Debian, Linux Mint, Fedora) bzw. BSD (FreeBSD) gearbeitet habe ist die Wahl des Betriebssystems auf Mac OS X gefallen. Und die Wahl der Hardware auf ein Mac Book Pro 13,3" gefallen. Ich gebe zu das es mich immer interessiert hat zu Erfahren, warum Niemanden den ich kenne, sein Mac OS X Gerät missen möchte.