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
Incremental build
Incremental build
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.
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
XSharp Development Team
chris(at)xsharp.eu
Incremental build
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
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
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Incremental build
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
XSharp Development Team
chris(at)xsharp.eu
Incremental build
Thank you! I will look into it.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.
Core i5, 2.5 GHzChris wrote:Btw, what CPU are you using?
The solution is split into approx. 10 projects.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.
Incremental build
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
MyClass2.prg -> MyClass2.obj
MyClass3.prg -> MyClass3.obj
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
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
Code: Select all
CLASS MyClass2
END CLASS
Code: Select all
CLASS MyClass3
END CLASS
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
Leonid
Incremental build
Leonid,
This is normal in languages such as Clipper and C/C++.
However it does not work like that in .Net.
Robert
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
The Netherlands
robert@xsharp.eu