Another Approach On Compiling ('almalgamation Concept')

[jan marco alkema]

This post has not my intention to change SQLYog. Only to give another approach on compiling the source code(s).

“compiling test results”:

If I compile from scratch (“rebuild”) the cvs sources of “sqlyog-20100807” it takes 324 seconds compiling time. After that I change in DataViewTable.cpp one character, the “build” time will take about 14 seconds (= 4,32 % of scratch compiling time).

I do it another way. I include all sources of (SQLYog, SQLite, libmysql, pcre, SciLexer and SQLite) in “1 file”, the compiling time will be 17 seconds! (=5,25% of scratch compiling time).

What I see in projects like SQLYog, is a lot of separate files, which include files that are necessary for the specific source file. I my opinion it is better to put all include files (like 'io.h', 'stdio.h', 'stlib.h', etc) that 'all' projects needs in top of the main program file (“WinMain.cpp”) . Try to remove all include files (like 'io.h', 'stdio.h', 'stlib.h', etc) in the rest of the source code.

My global design of WinMain.cpp:

Quote:

// all include files needed for the project

#include

#include

#include

.

.

//defines

//types definitions

//class definitions

//routine definitions

// WinMain routines

#include “..\..\common\error.cpp”

#include “..\..\common\hash.cpp”

#include “..\..\common\memory.cpp”

#include “..\..\common\filesystem.cpp”

#include “..\..\common\system.cpp”

#include “..\..\common\libmysql\libmysql.cpp”

#include “..\..\common\logdb.cpp”

.

.

#include “..\src\gui\AutoCompleteInterface.cpp”

#include “..\src\gui\BlobMgmt.cpp

.

.

#include “..\src\gui\QueryAnalyzerBase.cpp”

#include “..\..\common\pcre\pcre.cpp”

#include “..\..\common\SciLexer\SciLexer.cpp”

#include “..\..\common\SQLite\SQLite.cpp”

//WinMain, without loading SciLexer.dll

The Pro’s of my approach:

• Easely I can ‘put in’ of ‘extract’ parts of the code, like SQLite, etc.
• You can put code with the same functionality close to each other in an easy way.
• You can do standardization on code that have the same functionality. For example use 1 log routine of all program parts. Less code less potential bugs –)

The Cons’s of my approach

• It takes al lot of time to initial migrate the code to the ‘Amalgamation’ form.
• It is in my opinion impossible for a single developer to follow the (cvs) changes if the project like SQLite does not provide ‘Amalgamation’ form/concept.

Background information of Amalgamation:

Quote:

My ‘extraction’ out of http://www.sqlite.org/amalgamation.html

The amalgamation contains everything you need to integrate SQLYog into a larger project. Just copy the amalgamation into your source directory and compile it along with the other C code files in your project. You may also want to make use of the “sqlyog.h” header file that defines the programming API for SQLYog.

In addition to making SQLYog easier to incorporate into other projects, the amalgamation also makes it run faster. Many compilers are able to do additional optimizations on code when it is contained with in a single translation unit such as it is in the amalgamation. We have measured performance improvements of 1905% ((324 seconds/17 seconds) * 100) when we use the amalgamation to compile SQLYog rather than individual source files from scratch. The downside of this is that the additional optimizations often take the form of function inlining which tends to make the size of the resulting binary image larger.

[Khushboo]

Hi,

Thank you for this valuable information and for your suggestions.

Also, FYI: We migrated our project to Visual Studio 2010 (32 bit).

Please refer to: http://www.webyog.com/blog/2010/08/17/sqlyog-mysql-gui-8-6-rc3-released/

Thank You.

Regards,

Khushboo

[Author]

Posts