Is it true that platform independency is more of a myth today? Because programmers look for efficiency and power over portability which have to be compromised to some extent when achieving platform independency.

On the other hand architecture neutrality is welcomed because it provides a very powerful way to make a software which can dominate a particular operating system family.

My question is:

Lets consider a hypothetical situation where we have to pick either one of them.What should be compromised? Portability or Power?

I know this question is a bit subjective,but I'm looking for your views in general.

Thank you.


Is it right to accept a particular answer just for the sake of it,especially for a question that would be answered according to individual perspectives?

  • My problem is not that the question is subjective, but that it depends heavily on the application and potential platforms. Are we talking about smart phones or desktops? The constraints are different. Are we talking about primarily UI applications, primarily computational applications, or applications that interact more heavily with the OS? May 12, 2011 at 14:56
  • This question was closed during the STCI [software-engineering] cleanup.
    – yannis
    Mar 25, 2012 at 0:30

2 Answers 2


I rely on platform portability at the expense of power every day

I write my code on a Mac or Windows machine, and see it executed on a Linux machine. If I didn't have true platform portability this would be a nightmare.

Power is less of a compromise in my opinion because hardware is so cheap in comparison to developer time. If you need more throughput then throw more hardware at it. If you really need big throughput then start optimising your bottlenecks (most of which will likely be inter-process communication rather than operating system abstraction code).

  • +1: Me too. Forced to develop on Windows. Deploy on Linux.
    – S.Lott
    May 4, 2011 at 14:30

Depending on the application somewhere between 80% and 100% of the code will have no impact on performance, as long as it isn't grossly inefficient. For this code, correctness, maintainability and portability should be your priorities; there is no need to sacrifice any of these for marginal performance improvements.

Of the more critical code, somewhere between 80% and 100% can be made fast enough without sacrificing other qualities. Only consider sacrificing portability when you cannot reasonably meet your performance goals otherwise.

Once you have identified the truly critical bottlenecks, try to isolate small operations that can most benefit from non-portable optimisations. This might include inner loops written in assembly; use of operating system facilities to tweak thread priorities, lock code and data in RAM, or control cache usage; or using non-standard hardware acceleration. By separating this from the main body of code, it remains reasonably straightforward to replace this code either with a slower portable version (for testing on a platform other than the target), or with other versions optimised for different platforms (as future requirements call for more supported platforms).

  • GUIs are not really portable. A GUI that runs on multiple OSes might look native on one of them, but no more than one. May 12, 2011 at 14:58
  • @David: Indeed, GUIs and other platform-specific facilities are another reason to write non-portable code. My answer only considers the portability vs. efficiency tradeoff. May 12, 2011 at 15:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.