Visual LANSA Forum

I have a large LANSA repository (over 41,000 objects). When I refresh my VL repository with a new set of YML files, the IDE takes hours to auto-update this full list. However, if there's an error during this update procedure e.g. the IDE crashes with a LANSA.DMP output, then the whole process has to start again from the beginning. This is quite frustrating. It would be extremely helpful if the IDE committed all the work that it had already done (in terms of updating the local LANSA repository using the new YML files) and simply re-started where it left off prior to crashing. Starting from scratch is a very significant waste of time. In my case, this is day 3 of reloading the repository. So far none of my VL environments have been successful in loading the repository successfully with the new set of 41,000+ YML files. I'm also in the process of installing V15 EPC-40 to see if that resolves the IDE crash issue.

Has anyone else experienced the same issue, when the IDE starts auto-updating?

Update: My refresh finally completed, after 6 hours. Average processing speed was 1.9 YML files per second.

One way of making the load of a new VCS repository quicker is to ensure that you untick the 'Automatically compile changed objects' button.

This will mean that the code is loaded, but not compiled.

Also ensure that you haven't ticked 'Compile objects that use the changed object' as this can cause objects to get recompiled a number of times.

After you have loaded the VCS, you should be able to compile the objects by Right-Clicking on the VCS Folder (In the VCS view) and go to the bottom of the context menu which will likely say something like 'VCS Folder (PRT) : 41000 Objects' Selecting this will give you a context menu that has 'Compile' on it. - Select the compile option and it will submit a compile for all the objects.

Once the compiles are completed, you can retick the 'Automatically compile changed objects' button (this is in Options).

This is how i have gotten around this myself.

Thanks Brendan,
I made sure none of the compile options were selected. Otherwise the whole process could have taken a couple of days to complete.

In case LANSA R&D team takes notice: I will recommend making use of multiple CPU cores in this exercise (updating the LANSA repository based on YML file changes). Rather than working with just one CPU core, split this job onto multiple CPU cores e.g. by object type. All machines come with multiple CPU cores these days and folks can use SQL Server Developer edition which is capable of using multiple threads and this would really speed up the whole process.

Currently, on my 8 core workstation, six CPU cores sit idle as this job runs using just one CPU core and another gets used by SQL Server. Perhaps LANSA can consider taking advantage of the other CPU cores in this case.

Out of curiosity on this regard, sorry I dont have anything to help here,
Is the machine showing 100% use of that one cpu core with the task manager/performance tab?
How is the disk and the network? Is the SQL database and LANSA folder in an SSD disk? the same one?

Core usage around 60%+ on both cores, at most times when this update occurs.
Using SSD drives (500+ MB/S read/write) so absolutely no stress on HDD usage (Task Manager HDD Active Time never goes above 30%).
No network utilization in this case (it's all local).
Both LANSA and SQL Server are on the same SSD drive, but I see no stress on the HDD Active Time.
One should be able to replicate this issue, if you have a large LANSA repository to test with.