Re: Byte swapping efficiently

Tech-Archive recommends: Speed Up your PC by fixing your registry

On Wed, 3 May 2006 14:57:02 -0700, "Karl E. Peterson" <karl@xxxxxxxx>
wrote:

Hi John --

it's shifted the bottleneck away from byte-swapping, which was the
hoped outcome - it's now the simple mechanics of processing 55MB of
data that's holding the app up, but performance is now acceptable.

Depending on the layout of the data, and in what order(s) you need
to access it, you may find it an advantage to map the entire thing
into your process's memory space and treat it as one honkin-huge
array. For an idea of what I'm talking about, take a look at how
quickly this -- http://vb.mvps.org/samples/MapFile -- can
encrypt/decrypt huge files.

If I understand you right, that's pretty much what I'm doing anyway.
Basically, the file's read in two-byte chunks, then (if it's in
Motorola format) a byte-swap, as discussed, is performed for each
chunk. Other than byte-swapping issues, it's pulled into a
two-dimensional array and all other processing done with the data
entirely in memory.

If you're reading the file two bytes at a time, you can increase the
processing speed by quite a number (10+?) orders of magnitude!

How so? Are you thinking of disc access time or byte-swapping time?

Question: Would it be advantageous to have the byte-swapped data stored in
the original file? IOW, overwritten on the original data? If so, and
(especially!) if the above is also true, I'm sure we could kick the crap out
of your current timings.

The user can do that - read a file, which includes byte-swapping, then
write it out to a file of the same format except in native (Intel)
format. Trouble is, byte-swapping isn't the bottleneck any more -
Mike's suggestion removed that.

Something else is slowing it down now, and I don't know what it is -
see elsewhere in this thread for the code.
--
John Hatpin
.