Achieve better performance by rewriting to C++

[GEOEGII555]

Hello,

At enterprise quality programming LLC, performance is one of the top priorities that a company would have. The slower the performance is, the less clients a company would have. It's one of our top goals to maximize the performance.

That being said, while Java is a great programming language, it can't beat the speed of C and C++.

So, in order to maximize the performance of the fizz buzz: enterprise edition, and to beat the competitors, we need to rewrite Fizz Buzz: Enterprise Edition in C++.

While it's possible to write assembly code that has better performance than C++, it would cost too much. Most C++ compilers, such as the Microsoft MSVC compiler, generate very fast executables, where optimizing it further is not worth it.

Since we are on C++, our very serious enterprise project only supports the very serious enterprise platform called "Windows NT", we can leverage:

• The native Windows API. Java has a translator which translates the instructions for a specific operating system. However, since we're only on Windows NT, we can avoid doing such conversions and instead directly use the Windows API.

We also don't have to worry about destroying the performance and significantly increasing the dependency count when leveraging:

• The C++ standard library. It has a lot of useful things which don't destroy the performance, unlike Java. It also doesn't require a lot of dependencies (just an 11 gigibyte installation of Visual Studio) to run quickly and without performance issues.
  I haven't listed all of the upsides of rewriting our very serious enterprise project to C++.

The only downside of this is that we will be using the Windows API, which means that if some company ever decides to use Linukz as their operating system, even though it's not a serious business environment, they won't be able to use our project, which will lead to revenue loss.

What do you think about my proposal?

[GEOEGII555]

We could also use transactional NTFS to avoid data corruption on unexpected system crashes, however, unfortunately, Microsoft corporation has deprecated it. From their website:

TxF was introduced with Windows Vista as a means to introduce atomic file transactions to Windows. It allows for Windows developers to have transactional atomicity for file operations in transactions with a single file, in transactions involving multiple files, and in transactions spanning multiple sources – such as the Registry (through TxR), and databases (such as SQL). While TxF is a powerful set of APIs, there has been extremely limited developer interest in this API platform since Windows Vista primarily due to its complexity and various nuances which developers need to consider as part of application development. As a result, Microsoft is considering deprecating TxF APIs in a future version of Windows to focus development and maintenance efforts on other features and APIs which have more value to a larger majority of customers. The next section describes sample alternative methods to achieve similar results as TxF would for several types of application scenarios.

We could use one of the following alternatives, as suggested by the Microsoft corporation:

Applications updating a single file with "document-like" data: Many applications which deal with "document-like" data tend to load the entire document into memory, operate on it, and then write it back out to save the changes. The needed atomicity here is that the changes either are completely applied or not applied at all, as an inconsistent state would render the file corrupt. A common approach is to write the document to a new file, then replace the original file with the new one. One method to do this is with the ReplaceFile API.
Applications managing a set of structured data: Many applications manage some set of proprietary data structures of varying types as a means to store data. A significant challenge for these applications is the process of maintaining the integrity of internal pointers/references if a failure occurs during an update operation. Creating the mechanism for this is indeed a "hard problem", and therefore most applications will rely on a true database server to manage their dataset.

Two suggestions to help manage structured data are:

Microsoft provides the Extensible Storage Engine (ESE) inbox in Windows to enable applications to perform transacted data update and retrieval operations. For more information on the Extensible Storage Engine (ESE), please see https://msdn.microsoft.com/library/gg269259.aspx.
For applications that require a more powerful, robust, and scalable database provider, it is recommended that customers consider using the Filestream feature available with Microsoft SQL Server. For more information on SQL Filestreams, please see https://technet.microsoft.com/library/bb933993.aspx.

[GEOEGII555]

I may be able to implement this, but be aware that I don't have a lot of experience in enterprise development

[Tylersuard]

I may be able to implement this, but be aware that I don't have a lot of experience in enterprise development, so this might require some code and architecture review

I have seen roadblocks like this kill perfectly good projects. Please code directly in Prod.

[GEOEGII555]

I may be able to implement this, but be aware that I don't have a lot of experience in enterprise development, so this might require some code and architecture review

I have seen roadblocks like this kill perfectly good projects. Please code directly in Prod.

I don't have access to the production (uinverse) branch.

[GEOEGII555]

#694

[ryanolee]

It appears that c++ is simply too slow for our applications. It pains me to say that we will have to rethink this as a custom FPGA or if demand allows our own custom silicon. I have contacted TSMC: they have given me a 200 year lead time to get on their sub quantum node. ASML have been dragging their heels on making the lithography machine required and have given such asinine excuses "it is not physically possible".
I will keep you posted

• Steve from accounting

[GEOEGII555]

It appears that c++ is simply too slow for our applications.

This can't be true. C++ is a blasingly fast and (if used correctly) memory safe programming language.