Schlagwort-Archive: .NET

Rekursiv vs. Iterativ

In der dotnetpro 8/2011 hat Ralp Westphal im Artikel „Aus Baum mach Fluss“ zum Einstieg die Fakultätsberechnung in der rekursiven und in der iterativen Variante gezeigt. Seiner Meinung nach ist die iterative Variante einfacher zu verstehen, besonders für nicht-Mathematiker.
Ich fragte mich dann, welche Variante ist für den Computer einfacher zu verstehen, d.h. welche Variante ist performanter? Oder ist es egal, optimiert der Compiler schon so weit, dass beide Varianten in etwa gleich schnell sind?

Ich habe ein kleines Programm geschrieben, dass die Fakultät für verschiedene Werte mehrmals berechnet, um messbare Werte zu erhalten.
Hier die Resultate:

Factorial recursive and iterative
---------------------------------

10!
Recursive: 00:00:00.0390023
Iterative: 00:00:00.0220012

100!
Recursive: 00:00:00.2940168
Iterative: 00:00:00.1720099

1000!
Recursive: 00:00:02.5131437
Iterative: 00:00:01.0270588

10000!
Recursive: 00:00:25.0624335
Iterative: 00:00:09.4535407

Die rekursive Variante braucht also etwa 2.5 mal so lang wie die iterative. Und bei grossen Fakultäten kommt noch ein weiteres Problem hinzu: Es wird eine StackOverflowException geworfen, da jeder Rekursionsschritt einen Funktionsaufruf zur Folge hat, der einen Teil des Stacks beansprucht.

Fazit:
Der iterative Ansatz ist (mindestens in diesem Fall) auch für den Computer „einfacher zu verstehen“. Neben der besseren Performance ist aber auch die gebannte Gefahr des Stack Overflows ein wichtiger Grund, die iterative Varinate vorzuziehen.

Factorial Source Code

Slippery When Wet #5: The Process object or Optimization? don’t do it!

Schreibe eine Antwort

I proudly present to you the fifth in a infinite number of posts of “Slippery When Wet.” In these posts I show you a little bastard I stumbled on.

To get the memory usage information you can use the System.Diagnostics.Process class. As I wantet to check the memory usage regularly I kept the reference to the Process object in my class. But the value never changed anymore… Then I tried to get the Process object every time i needed the current memory size – and it worked.

So I read the documentation a little more carefully and got to this part:

The process component obtains information about a group of properties all at once. After the Process component has obtained information about one member of any group, it will cache the values for the other properties in that group and not obtain new information about the other members of the group until you call the Refresh method. Therefore, a property value is not guaranteed to be any newer than the last call to the Refresh method. The group breakdowns are operating-system dependent.

So I changed my code again to not get the Process every time I wanted the current memory size but call the Refresh method.

And what did we learn from this episode?

Michael A. Jackson („The First Rule of Program Optimization: Don’t do it (…)„) and Donald Knuth („(…) premature optimization is the root of all evil (…)„) are right. Don’t do optimization, especially not if you don’t really know what you are doing…

.NET Reflectors Erben

Schreibe eine Antwort

Nachdem redgate Anfangs Februar Ankündigte, dass der .NET Reflector kostenpflichtig wird, haben sich mehrere Nachfolger empfohlen:

Als erstes kündigte das Team von #develop das Tool ILSpy an.

Danach folgte Telerik mit JustDecompile.

JetBrains, welche sich auch für … verantwortlich zeichnen, kündigten dann auch noch einen Erben an, das Tool dotPeek.

Redgate kündigte währenddessen an, dass es weiterhin eine kostenlose Version von .NET Reflector geben wird. Es ist in diesem Bereich also noch einiges in Bewegung…

Auswahl der zu benutzenden Framework-Version

Schreibe eine Antwort

Um eine .net-Applikation mit einer bestimmten Framework-Version auszuführen, kann diese im App.Conifg-File angegeben werden. Mit folgendem Beispiel wird die Anwendung mit dem Framework 1.1 ausgeführt, wenn man den Kommentar um das andere supportedRuntime-Tag setzt, wird das Framework 2.0 verwenden.

< ?xml version="1.0" encoding="utf-8">
<configuration>
<startup>
<supportedruntime version="v1.1.4322"/>

</startup>
</configuration>

Die Datei muss dabei dem Dateinamen der Anwendung mit angehängtem .config entsprechen, z.B. für die Anwendung „MyApp.exe“ heisst die Datei „MyApp.exe.config“.

Slippery When Wet #2: SCOPE_IDENTITY and SqlDataReader

Schreibe eine Antwort

I proudly present to you the second in a infinite number of posts of “Slippery When Wet.” In these posts I show you a little bastard I stubled on.

Imagine you have a database table with a cloumn id of the data type integer that has set the IDENTITY. You use a stored procedure to insert a new entry into this table. Inside this stored procedure you use the SCOPE_IDENTITY() function to get the identifier created for this row. With RETURN SCOPE_IDENTITY() you give the identity to the caller.

You call this stored procedure from a SqlComand with ExecuteReader() that returns you an SqlDataReader object.

From this SqlDataReader you read now the identifier with GetInt32().

Wrong !

This will give you an InvalidCastException. SCOPE_IDENTITY()’s return type is numeric, although your identifier column is an integer. SqlDataReader’s GetXY functions do not convert the data and throw the exception when the data is not already of the right type.

The first solution

You can read the value with GetDecimal() and cast the value to an int:

int identifier = (int)reader.GetDecimal(0);

The second solution

You cast the identifier inside the stored procedure und return it already as an integer:

SELECT CAST(SCOPE_IDENTITY() AS INT)

Whatever solution you choose, take care that you use always the same inside your application.