MapServer rendering speed improvement

[sdlime]

This is a follow on to bug #2601. A portion of that dicussion is being reformed under this ticket. The original comment by nnikolov was:

---

I did some additional work and testing on the issue implementing it on CentOS 32 bit machine (The old implementation was on Fedora 64 bit). The problem was the definition of 64 bit pointer and its use together with SWAP_EIGHT_BYTE macro.

The solution consists of: First, the corresponding temporary pointer needs to be defined as “long long” so to become pointer to 64-bit data. Secondly, the SWAP_EIGHT_BYTE macro needs to be slightly changed to make the compiler to recognise the 64-bit constants in the macro:

#define SWAP_EIGHT_BYTES(data) \ ( ((data >> 56) & 0x00000000000000FFULL) | ((data >> 40) & 0x000000000000FF00ULL) | \ ((data >> 24) & 0x0000000000FF0000ULL) | ((data >> 8) & 0x00000000FF000000ULL) | \ ((data << 8) & 0x000000FF00000000ULL) | ((data << 24) & 0x0000FF0000000000ULL) | \ ((data << 40) & 0x00FF000000000000ULL) | ((data << 56) & 0xFF00000000000000ULL) )

It works fine and it should be good for both 64 and 32-bit machines and allow the use of the SWAP_EIGHT_BYTE macro as well.

---

Devs "in the know" wanted to push this to 5.4 pending more testing etc...

Steve

[sdlime]

With performance testing around the corner this ticket caught my eye. Any opinions on if this would be a good thing to look at for the upcoming 5.6 release?

Steve

[pramsey]

This optimization would only really kick in for big-endian architectures, if I recall correctly. My vote would be no, best to not do it late in the cycle.

[pramsey]

Can we be sure that "long long" is in fact interpreted as a 64-bit integer on all our target architectures? I am -0 on this patch because it adds this potential architecture issue while only addressing a very small performance corner case for big-endian architectures. There are times to leave well enough alone, this would be one of them.

[warmerdam]

I concur with Paul.