TOPIC:

Hallo!

Da dies mein erster Beitrag ist stelle ich mich kurz vor: Mein Name ist Kai, ich komme aus NRW und arbeite seit über 20 Jahren mit VO. Bis heute bearbeite und pflege ich nach wie vor mit VO einige größere Projekte. Die Umstellung auf Vulcan war schon 2014 geplant wofür ich ein Projekt portiert habe, was auch mit nur wenigen Problemen fehlerfrei geklappt hat. Was schon bei Vulcan auffiel und jetzt bei X# auffällt ist, dass der Compiler gefühlt ewig läuft bis die .exe erzeugt wurde. Was bei VO in Sekunden erledigt ist braucht in C# bei einem meiner Projekte über 25 Minuten, und das nur für die .exe, diverse DLLs noch gar nicht mitgerechnet. Das macht natürlich jeden wirtschaftlichen Einsatz von Anfang an undenkbar und wird besonders ärgerlich wenn man dieses oder jenes ausprobieren möchte, man sich mit der Suche nach Fehlern rumplagen muss oder schlicht einfachste Tippfehler eingebaut hat.

Daher die Frage: Gibt es eine Möglichkeit die elendig langen Compilierzeiten zu reduzieren oder wie handhabt ihr das Problem?

Gruß

Kai

Hallo Kai,

so lange sollte kein Compiler-Lauf dauern.....

VO arbeitet komplett anders als X#/C#/Vulcan.Net: es werden immer nur die geänderten Entities kompiliert, daher geht das sehr schnell.
Wie groß ist denn Deine Exe, bzw. wie viel Quellcode steckt da drin?

Normalerweise sollte eine Modularisierung die Lösung bringen, aber ich denke, da läuft irgendwas schief.

Und noch was: der Compiler der Community-Version ist meines Wissens nach etwas langsamer, da er Debug-Code enthält.

Wolfgang

Kai,

25 minutes is unacceptable.
What is the size of your app? (lines of code, modules etc)
What are the specs of your computer ?

Robert

Hello,

Compiling 1 change in the project we are converting takes about a minute. If VO invalidates multiple libraries and the main program(s) using them, due to a change in a commonly used library, I can have it compiled and re-running in <10 seconds which is less than just restarting a .Net based program. Not only X#, also C#.

So the progress of .Net has brought us half an hour or more waiting time a day instead of a few minutes a day like in VO.

Dick

Robert,

robert wrote: 25 minutes is unacceptable.
What is the size of your app? (lines of code, modules etc)
What are the specs of your computer ?

Just to be clear, I think Kai mentioned that this delay is with a c# program, not with X#. Still indeed unacceptable, but I'm guessing there something very special about it.

Hello!

The .exe-file which was generated by C# has a size of 6442 KB.
The .exe file which was generated by VO has a Size of 32660 KB
The VO-AEF-File has a Size of 25727 KB

Additionally some dll files are used which in total have a size of 5500 KB (generated by C#).

The VO-AEF-File contains 17200 Entities for the .exe file and the AEF-Files for the DLLs contain totaly 16250 Entities.

I use a normal PC with a Intel core I5 processor, 8 Gig RAM and SSD-Harddisc. The complete compilation of the whole Project including all DLL-Files with VO takes less than 4 Minutes.

Hi Kai,
C# or X#?
If C#: how do you have moved VO code over to C#?
Wolfgang

Hi Wolfgang.

Sorry, X# of course.

I used the X# VOExporter from the XIDE (Help -> X# -> Run VOExporter)

Hi Kai,
since you have written "C#" for more than one time, I preferred to ask.
Of course, this compile time is too long.
Maybe 8 GB of memory may be a bit small - dou you are using XIDE or Visual Studio?
And when you look at the taskmanager: your memory is full with other applications?
Do you have all your code on your local SSD?
And what X# version do you are using?
Wolfgang

Hi Wolfgang!
I'm using XIDE. All Code is on the local SSD. I'm using Version 2.9a. I downloaded it just a few Weeks ago because since my Vulcan test I lost Interest on migration of the VO-Code to the .net world because Vulcan was also significantly slower than VO. But now I have some tasks to solve that would be easier to solve with the .net framework.
Maybe 8 GB is to small, but I have never 100% memory usage during compilation. In most cases memory usage is around 90 percent.

Kai

Hi Kai

FWIW and it is just a guess, something like this suggests to me that some of your code may have become duplicated in the transfer process leading to multiple compilations of the same thing.

Terry

Hi Kai,

How many compiler warnings do you get after you compile? If they are several thousands, it's possible that the bottleneck is actually not the compiler, but the communication between the compiler and XIDE, transferring all those warnings. If that's the problem, we can find a solution quickly.

But I am not sure if that's indeed the problem. The most reliable way to debug this and find for sure what's causing it and fix it is to be able to test it in our machines. Would it be possible to zip and send me/Robert (or better post it in a file sharing service) the complete XIDE project? If it's a problem in XIDE, then it will be myself who will need to fix it, if it's due to the compiler that will be Robert or Nikos.

Hi Chris!

I have less than 550 warnings. Most "The variable xxx is assigned but its value is never used."
I have fixed nearly all other warnings. When the exe-file is generated it is running fine.
I will test the Compiler in the next days on an other Hardware with mor RAM.

Kai

Hi Kai,

Then most likely it's something very specific in your code that the compiler is not optimized form. Maybe a huge amount of defines, maybe globals, maybe extremely extensive use of UDC commands, maybe something else that I am not thinking about. Most probably it will be easy enough to fix/improve it in the compiler, but first we need to know what that is..

Could you also please select from the XIDE menu View-View Project Statistics and send a screenshot of the window that shows some info for your project? Maybe this could also give some idea..

Hi Chris!

Here is a Screenshot with the project-statistics.

I am using nearly 1400 constants in this project and only the STD.UDC no other UDC-files.

Kai

What do you think is a normal and acceptable compilation time for a project like this on a regular PC? It would be interesting information if I test it on another PC in the next few days.

Kai,
I think over 600 files and over 300.000 source code lines is a quite large for a single application.
I would personally split the app up in some "core" code, some subsystems (reporting, data entry, system table maintenance etc) and a main app that brings this all together.
I know that this may be difficult due to dependencies between things, but in the long run this will make your app much easier to maintain.
To break the link between things you should consider to add some interfaces (these can be in the "core" code) and then implement these interfaces. Classes in the data entry then do not need to directly have access to reports for example, but they know about the IYourReport interface and can "communicate" with the reports through this interface.
And they can for example call YourShell:CreateReport() with the name or classname of a report and get an object back that implements IYourReport.

It will be a bit of work in the beginning but you will be rewarded with much faster edit-compile-test times.
And when applied properly it will also allow you to replace a single component when you find an issue.

Robert

Hi Kai,

In normal circumstances, it should take a minute or two at the very most. The largest single exe app I have (a standard VO-type app), is one with 180,000 lines of code and in the Public X# compiler version it takes 21 seconds to compile on my i5-8400 @ 2.8 GHz with 8 GB of memory and an SSD (but after making sure nothing else on my PC is using CPU or RAM). The compiler version that the subscribers get and which is usually around twice as fast, takes only 9 seconds to compile it on my machine.

So normally with your 430,000 line app, even the public version shouldn't take more than a minute or so. And that's if as Robert said this is a single app and it is not divided into dlls. It is not clear from the screenshot unfortunately, is this app indeed a single exe one, or do you have separate support dlls?

Hi Chris!

The .exe depends on a large . DLL with another 12945 entities and another 1000 constants. I added a screenshot to the attachments. It is interesting that the .dll file compiles in about 5 minutes, which is still far from a minute or less, but is significantly faster than 25 minutes of the .exe file.

Many of the constants from the .dll-file are used in the .exe file and are not redefined separately in the exe file's project. Could this be a problem because the compiler needs to find the constants in an external dll-file?

Kai

Ah, sorry, I looked at the screenshot more carefully and I see this is 400K+ lines for the exe alone. As Robert said, it would be a very good idea to divide this into at least 2-3 separate dlls, in order manage compiling small changes a lot better.

But still, it should take nowhere near 25 minutes to compile it normally. Maybe, as Wolfgang said, available RAM is the problem. Even if usage remains at 90% this might mean that the compiler all the time releases and allocates again memory blocks, maybe the OS swap parts to the disk etc, in order not to fill it up to 100%.

What about the libraries in your project? How large are they (in lines of code) and how much time does it take to compile each one of them?