Python ist krass

Momentan bin ich “gezwungen”, Software in Python zu schreiben. Und nach einigen Programmierer-Tagen bin ich immer mir noch nicht sicher, ob ich Python mag oder nicht. Einige Sachen sind cool, andere nicht und allzu häufig muss ich feststellen, dass Python ein riesiger Flickenteppich ist. (Allein schon, dass es “alte” und “neue” Klassen gibt – von der Syntax her – und dass diese nicht kompatibel sind, spricht Bände.)

Heute bin ich dafür mal wieder auf ein Konstrukt gestoßen, dass krass und cool zugleich ist:

for i in foo:
  ...
else:
  ...

Es gibt hier also for-Schleifen mit else-Block. Und zwar wird der else-Block ausgeführt, wenn die Schleife komplett durchgelaufen ist (d.h. nicht durch ein break vorzeitig beendet wurde). Ziemlich praktisch.

Referenz

Group box panel with GWT

I’m currently participating on a software development project using the Google Web Toolkit (GWT). While developing the GUI for a certain part of this project, I came across the need of a group box panel.

For those who don’t know what a group box is; here is an example:

groupbox.jpg

Fortunately this type of panel is directly supported by HTML throught the <fieldset> tag. Unfortunately it isn’t supported by GWT (yet). However, it’s very simple to implement this using the SimplePanel class provided by GWT.

import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.ui.SimplePanel;

/**
 * A group box panel (i.e. a frame where to which a caption can be
 * attached). The caption can be set via {@link #setCaption(String)}. 
 * The content can be set via {@link SimplePanel#setWidget()}.
 *
 * @author Sebastian Krysmanski
 */
public class GroupBoxPanel
  extends SimplePanel {

  private final Element m_caption = DOM.createLegend();
  
  public GroupBoxPanelImpl() {
    super(DOM.createFieldSet());

    DOM.appendChild(getContainerElement(), this.m_caption);
  }

  public GroupBoxPanelImpl(String caption) {
    this();
    setCaption(caption);
  }

  public String getCaption() {
    return DOM.getInnerText(this.m_caption);
  }

  public void setCaption(String caption) {
    DOM.setInnerText(this.m_caption, caption);
  }
}

This code is released as public domain.

.NET – Array.Clear() vs. array[x] = 0 – Performance

So, yet another performance test for .NET. This time I was checking what’s the fastest way to clear an array (i.e. setting all array members to 0 or null).

The two contesters are:

  • array[x] = 0 (iterate over the array and simply set the values to 0)
  • Array.Clear()

Here are some results:

Clearing 5,000,000,000 items per test

Array.Clear() - Array size: 5 : 31.564s
Array[x] = 0  - Array size: 5 : 4.428s

Array.Clear() - Array size: 25 : 7.477s
Array[x] = 0  - Array size: 25 : 3.315s

Array.Clear() - Array size: 50 : 4.414s
Array[x] = 0  - Array size: 50 : 3.629s

Array.Clear() - Array size: 100 : 2.571s
Array[x] = 0  - Array size: 100 : 3.292s

Array.Clear() - Array size: 500 : 0.935s
Array[x] = 0  - Array size: 500 : 3.014s

Array.Clear() - Array size: 50000 : 0.621s
Array[x] = 0  - Array size: 50000 : 2.948s

In each test 5 billion int array items were cleared (that’s 20 GB). Tests was run first with a small array whose size was increased after each test run. The test were run as Release build.

As you can see:

  • For small arrays, array[x] = 0 is faster.
  • For large arrays, Array.Clear() is faster.
  • They’re about equally fast for array sizes between 50 and 100. (My guess is, somewhere around 75.)

And here’s the source code for this test:

ArrayClearTest.cs

.NET Locking Performance

Just a quick overview over the different lock types and their performance in .NET.

For this test, the following method was called as fast as possible for 4 seconds:

private void TestMethod() {
  lock (this) { // this locking is replaced depending on the locking type
    counter++;
  }
}

Here are the results:

Locking Type Calls per second Factor
No locking (fastest possible) 470,972,276 19.61
Interlocked.CompareExchange 62,439,529 2.60
lock keyword 37,554,119 1.56
SpinLock (without owner tracking) 34,489,245 1.44
ReaderWriterLockSlim with LockRecursionPolicy.NoRecursion 25,214,451 1.05
ReaderWriterLockSlim with LockRecursionPolicy.SupportsRecursion 24,013,488 1.00

Full source code: Program.cs

SQLite Performance (RFC)

I’m currently working on a cross-platform SQLite .NET wrapper. At the moment it’s not really thread-safe. So, I was looking for ways of making it thread-safe.

Basically, there are two ways to do this:

  1. Share a single connection among all threads and use .NET locking mechanisms.
  2. Let each thread have its own connection (thus no .NET locking would be required).

To be able to make this decision, I did some performance tests and – assuming I did them right – got some interesting results you can read after the break.

Read more →