Skip to main content
added 16 characters in body
Source Link
Der Kommissar
  • 20.3k
  • 4
  • 70
  • 158

Another suggestion, to go on top of Heslacher's:

Make the (short)((short)inputBuffer[... a set of methodsmethod.

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static short BytesToShort(byte a, byte b)
{
    return (short)(a << 8 | b);
}

The MethodImplOptions.AggressiveInlining enumeration value tells the C# compiler to try to inline the method as much as possible. That is, if you come form a C/C++ environment, it'sit is very similar to macro's.

The C++ macro:

#define LERP(a,b,c) (((b) - (a)) * (c) + (a))

In C# could be written as:

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static double Lerp(double a, double b, double c)
{
    return (b - a) * c + a;
}

And effectively be the same thing. The compiler would try to inline the method body instead of the method whenever possible.

This should help performance, while allowing you to move some of the more mundane code away from the main area you would be working.

Note: this does not guarantee that this is the choice the compiler would make, nor does it preclude you from doing other optimization strategies. However, for a method this small and simple, it would likely make that choice in the end.

https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions(v=vs.110).aspx

This means, that you could essentially do:

for (int i = 0; i < sensorData.Length; i++)
{
    sensorData[i] = BytesToShort(inputBuffer[startposition++], inputBuffer[startPosition++]);
}

With no ill-effects.

Another suggestion, to go on top of Heslacher's:

Make the (short)((short)inputBuffer[... a set of methods.

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static short BytesToShort(byte a, byte b)
{
    return (short)(a << 8 | b);
}

The MethodImplOptions.AggressiveInlining enumeration value tells the C# compiler to try to inline the method as much as possible. That is, if you come form a C/C++ environment, it's similar to macro's.

#define LERP(a,b,c) (((b) - (a)) * (c) + (a))

In C# could be written as:

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static double Lerp(double a, double b, double c)
{
    return (b - a) * c + a;
}

And effectively be the same thing. The compiler would try to inline the method body instead of the method whenever possible.

This should help performance, while allowing you to move some of the more mundane code away from the main area you would be working.

Note: this does not guarantee that this is the choice the compiler would make. However, for a method this small and simple, it would likely make that choice in the end.

https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions(v=vs.110).aspx

This means, that you could essentially do:

for (int i = 0; i < sensorData.Length; i++)
{
    sensorData[i] = BytesToShort(inputBuffer[startposition++], inputBuffer[startPosition++]);
}

With no ill-effects.

Another suggestion, to go on top of Heslacher's:

Make the (short)((short)inputBuffer[... a method.

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static short BytesToShort(byte a, byte b)
{
    return (short)(a << 8 | b);
}

The MethodImplOptions.AggressiveInlining enumeration value tells the C# compiler to try to inline the method as much as possible. That is, if you come form a C/C++ environment, it is very similar to macro's.

The C++ macro:

#define LERP(a,b,c) (((b) - (a)) * (c) + (a))

In C# could be written as:

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static double Lerp(double a, double b, double c)
{
    return (b - a) * c + a;
}

And effectively be the same thing. The compiler would try to inline the method body instead of the method whenever possible.

This should help performance, while allowing you to move some of the more mundane code away from the main area you would be working.

Note: this does not guarantee that this is the choice the compiler would make, nor does it preclude you from doing other optimization strategies. However, for a method this small and simple, it would likely make that choice in the end.

https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions(v=vs.110).aspx

This means, that you could essentially do:

for (int i = 0; i < sensorData.Length; i++)
{
    sensorData[i] = BytesToShort(inputBuffer[startposition++], inputBuffer[startPosition++]);
}

With no ill-effects.

Source Link
Der Kommissar
  • 20.3k
  • 4
  • 70
  • 158

Another suggestion, to go on top of Heslacher's:

Make the (short)((short)inputBuffer[... a set of methods.

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static short BytesToShort(byte a, byte b)
{
    return (short)(a << 8 | b);
}

The MethodImplOptions.AggressiveInlining enumeration value tells the C# compiler to try to inline the method as much as possible. That is, if you come form a C/C++ environment, it's similar to macro's.

#define LERP(a,b,c) (((b) - (a)) * (c) + (a))

In C# could be written as:

[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static double Lerp(double a, double b, double c)
{
    return (b - a) * c + a;
}

And effectively be the same thing. The compiler would try to inline the method body instead of the method whenever possible.

This should help performance, while allowing you to move some of the more mundane code away from the main area you would be working.

Note: this does not guarantee that this is the choice the compiler would make. However, for a method this small and simple, it would likely make that choice in the end.

https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions(v=vs.110).aspx

This means, that you could essentially do:

for (int i = 0; i < sensorData.Length; i++)
{
    sensorData[i] = BytesToShort(inputBuffer[startposition++], inputBuffer[startPosition++]);
}

With no ill-effects.