Justification for using non-portable code

Question

How does one choose if someone justify their design tradeoffs in terms of optimised code, clarity of implementation, efficiency, and portability?

A relevant example for the purpose of this question could be large file handling, where a "large file" is "quite a few GB" for a problem that would be simplified using random-access methods.

Approaches for reading and modifying this file could be:

1. Use streams anyway, and seek to the desired place - which is portable, but potentially slow, and is not clear - this will work for practically all OS's.
2. map the relevant portion of the file as a large block. Eg, mmap a 50MB chunk of the file for processing, for each chunk - This would work for many OS's, depending on the subtleties of implementing mmap for that system.
3. Just mmap the entire file - this requires a 64-bit OS and is the most efficient and clear way to implement this, however does not work on 32-bit OS's.

Answer 1

Not sure what you're asking, but part of the design process is to analyze requirements for portability and performance (amongst other factors).

If you know you'll never need to port the code, and you need absolutely the best performance, then you adjust your implementation accordingly. There's no point being portable just for its own sake.

Note also that if you want both performance and portability, there's nothing stopping you from providing an implementation for each platform. Of course this will increase your cost, so really, its up to you to prioritize your needs.

Answer 2

Without constraints, this question rationally cannot be answered rationally.

You're asking "what is the best color" without telling us whether you're painting a house or a car or a picture.

Constraints would include at least

• Language of choice
• Target platforms (multi CPU industrial-grade server or iPhone?)
• Optimizing for speed vs. memory
• Cost (who's funding this and is there a delivery constraint?)

No piece of software could have "ultimate" portability.

An example of this sort of problem being handled using a variety of methods but with a tight constraint both on the specific input/output required and the measurement of "best" would be the WideFinder project.