.NET Performance: primitive type vs. struct

For a project I was wondering what’s the performance penalty of using a C# struct (containing only one field) over using a local variable directly; i.e.:

int myVar;

vs.

struct MyStruct {
  int MyVar;
}

The result: There’s no (real) difference!

Here are some stats (“Release” build):

Running each test 50,000,000,000 times

Running 'UseLocalVar'...
Done in 61329.359 ms
Running 'UseStructField'...
Done in 61414.885 ms
Running 'UseStructProperty'...
Done in 121383.416 ms

The first two results are what I was talking about. The third result uses a property instead of a field in the struct. It’s two times slower.

Here’s the code for the benchmark:

using System;
using System.Diagnostics;

class Benchmark {
  const long LOOPS = 50000000000;

  static void Main(string[] args) {
    Benchmark benchmark = new Benchmark();

    Console.WriteLine("Running each test {0:0,0} times", LOOPS);
    Console.WriteLine();

    Console.WriteLine("Running 'UseLocalVar'...");
    Stopwatch stopWatch = Stopwatch.StartNew();
    int test = 0;
    for (long x = 0; x < LOOPS; x++) {
      test += benchmark.UseLocalVar((int)x);
    }
    TimeSpan elapsed = stopWatch.Elapsed;
    Console.WriteLine("Done in {0:0.000} ms", elapsed.TotalMilliseconds);


    Console.WriteLine("Running 'UseStructField'...");
    stopWatch = Stopwatch.StartNew();
    test = 0;
    for (long x = 0; x < LOOPS; x++) {
      test += benchmark.UseStructField((int)x);
    }
    elapsed = stopWatch.Elapsed;
    Console.WriteLine("Done in {0:0.000} ms", elapsed.TotalMilliseconds);


    Console.WriteLine("Running 'UseStructProperty'...");
    stopWatch = Stopwatch.StartNew();
    test = 0;
    for (long x = 0; x < LOOPS; x++) {
      test += benchmark.UseStructProperty((int)x);
    }
    elapsed = stopWatch.Elapsed;
    Console.WriteLine("Done in {0:0.000} ms", elapsed.TotalMilliseconds);
  }

  int UseLocalVar(int val) {
    int test = val;
    test = test + val;
    return test;
  }

  int UseStructField(int val) {
    TestStructField test = new TestStructField(val);
    test.Value = test.Value + val;
    return test.Value;
  }

  int UseStructProperty(int val) {
    TestStructProperty test = new TestStructProperty(val);
    test.Value = test.Value + val;
    return test.Value;
  }

  private struct TestStructField {
    public int Value;

    public TestStructField(int value) {
      this.Value = value;
    }
  }

  private struct TestStructProperty {
    public int Value { get; set; }

    public TestStructProperty(int value) : this() {
      this.Value = value;
    }
  }
}

Fight spam with disposable email addresses

Interlude

There’s spam on the Internet, alright. Lots of it. You receive spam when spammers get hold of your email address. How do they do this?

  1. A friend of yours got himself infected with a virus/worm/trojan horse. This virus reads your friend’s address book and sends all email addresses in it to a spam server.
  2. Spammers try to guess common email addresses, like sales@mydomain.com or mail@mydomain.com.
  3. A lot of websites require you to give them your email address.

    • These websites can (potentially) be hacked and the hackers can download your email address (among all others) from the website.
    • The website puts your email address in plain text somewhere where it can (easily) be found by email harvesting programs.

You can’t really do anything about point 1. You can kick your friend’s butt for not having an anti-virus program running on his computer or for surfing on suspicious websites. But then (in most cases) it may not be his fault altogether.

You can avoid the problems of point 2 by not using so commonly used email addresses (but this may not be possible for everyone).

What this article is about is point 3.

Before we get started, here’s some good advice (not really related to what’s following):

If you have a website of your own don’t ever put your email address in plain text on your website. Use a contact form, JavaScript obfuscation, or even an image but don’t put it there in plain text.

The Concept

How do you cope with point 3? Easy:

You provide a different email address for each website that requires an email address.

Doing this has several advantages:

  • If you receive spam over such a special email address, you immediately know which website is the culprit.
  • If you receive spam, you simply delete the email address. No more spam. You can’t do this if you provided the website with your main email address (obviously).

Although this concept is nice, there’s one big requirement for it:

Creating and deleting email addresses must be extremely easy/fast. Otherwise you won’t do it, trust me.

Implementation

So, how do we do this? We use a so called catch-all email address.

Email flow chart

This requires that you have the ability to create such an email address. Your best chance is if you have your own domain and your domain provider allows it.

Then:

  1. Create a sub domain for these email addresses. (Don’t use your TLD if you can because a sub domain is not that easy to guess.) For example, create spam.mydomain.com.
  2. Create a catch-all email address for this sub domain. This can either be a mailbox or a forwarding.

That’s it.

Now, when register at a website called “my-fancy-shop”, use my-fancy-shop@spam.mydomain.com as email address. “Creating” a new email address couldn’t be easier, could it?

If you want to delete/block an email address, simply create a forwarding to a non-existing email address (like reject@mydomain.com). Then this email address won’t be caught by the catch-all email address but instead use its forwarding address.

P/Invoke Tutorial: Basics (Part 1)

P/Invoke is a way of calling C/C++ functions from a .NET program. It’s very easy to use. This article will cover the basics of using P/Invoke.

Note: This tutorial will focus on Windows and thus use Visual Studio. If you’re developing on another platform or with another IDE, adopting the things in this article should be easy enough.

Read more →

Logging from C/C++ on Android (instead of debugging)

With the Android NDK Google lets us write C/C++ code for Android. I don’t like writing C/C++ code because it’s error-prone but sometimes there’s no other way.

Unfortunately (this is the “I don’t like this” part), debugging Android C/C++ code is terribly difficult. If you don’t have a week to get the debugging toolchain working, and if you only need some quick and temporary solution, logging may be an alternative.

Read more →

Unicode, UTF-8, WTF?

Ever wondered what Unicode is and how it relates to UTF-8, UTF-16, and so on? Or did you stumble over “code points” and didn’t know what the difference to characters is?

Then you should try out the shiny new Unicode Explorer.

For some basics, click on the “Basics” link in the Unicode Explorer.

MayaStudios Unicode Explorer