Incremental build

Have some feedback and input to share?
Don't be shy and drop us a note. We want to hear from you and strive to make our site better and more user friendly for our guests and members a like.
Post Reply
Serggio
Posts: 46
Joined: Sun May 14, 2017 5:03 pm
Location: Ukraine

Incremental build

Post by Serggio »

Hello!
Have to complain on a slow build time. And that would be bearable but the problem is that even a "void" build after making NO changes or just resaving a file, adding extra space or a comment takes almost the same amount of time!
Full rebuild of a solution has taken 04:28
After making changes to a single comment: 03:40. It is 78% of the full build time.
And I haven't even started to develop new things, being yet on a transporting phase.
The size of solution's source code (PRGs + XSFRMs) is about 11 Mb, and that is just the very beginning.
The source code is clean: no errors nor warnings.

Maybe there is a way to identify whether some code is already compiled/built so there is no need to rebuild it? In CAVO the repository contained all those links and stuff to make compilation as "precise" as possible. You've already made SQLite DB to cache identifiers, maybe that can be somehow applied to reducing the amount of code to compile?

Longing for any progress on this part,
Serggio
User avatar
Chris
Posts: 4898
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

Incremental build

Post by Chris »

Hi Serggio,

10 MB should be around 300K lines of code, for which a few minutes of compiling sounds indeed way too much. I am currently working on a project with 200K lines and it takes half a minute or less to completely rebuild.

Have you checked if it's one or two of the projects that is taking the majority of time to compile and maybe the rest compile quickly? Maybe there's something specific about those projects that's bottlenecking the compiler and we need to look into it.

Something you can do in order to tell VS not to always rebuild everything, is to open Build->Configuration Manager, then uncheck the "Build" option from all the projects in the list. This way VS will no longer rebuild everything when you make s change in a library, you will have control yourself on which ones and when to rebuild. This will definitely reduce the time spent on building, but I still think we need to find out the original reason for the slow build.

Btw, what CPU are you using? Could it also be that there are many other process running in the background that are heavily using resources (CPU/memory/disk)? Also I assume you are using the FOX version of the compiler, right? Because the public one is much slower indeed.
Chris Pyrgas

XSharp Development Team
chris(at)xsharp.eu
User avatar
wriedmann
Posts: 3754
Joined: Mon Nov 02, 2015 5:07 pm
Location: Italy

Incremental build

Post by wriedmann »

Hi Serggio,
AFAIK the only possibility to save time is to split up your project in more libs.
Then you can rebuild only the changed libs.
The VO repo helds not only the source code, but also the compiled code, so the build-run cycles are very short. Unfortunately this is not more possible with .NET because every compile is a full compile and link.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
User avatar
Chris
Posts: 4898
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

Incremental build

Post by Chris »

Oh, Serggio, is Wolfgang right, is it only one project you have in the solution? If yes, then I agree the best way is to divide it in 2-3 separate libraries.
Chris Pyrgas

XSharp Development Team
chris(at)xsharp.eu
Serggio
Posts: 46
Joined: Sun May 14, 2017 5:03 pm
Location: Ukraine

Incremental build

Post by Serggio »

Chris wrote: Something you can do in order to tell VS not to always rebuild everything, is to open Build->Configuration Manager, then uncheck the "Build" option from all the projects in the list. This way VS will no longer rebuild everything when you make s change in a library, you will have control yourself on which ones and when to rebuild. This will definitely reduce the time spent on building, but I still think we need to find out the original reason for the slow build.
Thank you! I will look into it.
Chris wrote:Btw, what CPU are you using?
Core i5, 2.5 GHz
Chris wrote: Oh, Serggio, is Wolfgang right, is it only one project you have in the solution? If yes, then I agree the best way is to divide it in 2-3 separate libraries.
The solution is split into approx. 10 projects.
leon-ts
Posts: 435
Joined: Fri Feb 03, 2017 1:43 pm

Incremental build

Post by leon-ts »

Hi,
a very interesting topic!

Maybe Serggio has the following situation in mind (example):
There is a project (DLL) that represents components for a specific service (MyService.DLL).
Let it have three unrelated classes.

MyClass1.prg -> MyClass1.obj

Code: Select all

CLASS MyClass1
END CLASS
MyClass2.prg -> MyClass2.obj

Code: Select all

CLASS MyClass2
END CLASS
MyClass3.prg -> MyClass3.obj

Code: Select all

CLASS MyClass3
END CLASS
Linker: MyService.DLL = MyClass1.obj + MyClass2.obj + MyClass3.obj

If I make changes to only one of the classes, then I expect the compiler to compile only the changed PRG file, get the object file, and then link it with the already existing unchanged object files from other PRG files.

I don't know if this is implemented in VO, but visually it happens that way. If I change one MEF in any library that is not linked to other MEFs, then only one MEF will be compiled. And not even the whole MEF, but only the changed Entities in it.

How difficult is it to do this in XSharp? I think the problem described above worries all owners of large projects.

Best regards,
Leonid
Best regards,
Leonid
User avatar
robert
Posts: 4518
Joined: Fri Aug 21, 2015 10:57 am
Location: Netherlands

Incremental build

Post by robert »

Leonid,

This is normal in languages such as Clipper and C/C++.
However it does not work like that in .Net.

Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
Post Reply