Software compilation speed

[stokefc22]

Hi All,
Apologies in advance for my patchy explanation of an issue I'm currently experiencing and possibly posting in the wrong forum but here goes....

OK so rightly or wrongly(no hope of a change!!) we have a 'development environment' setup on our local machines where our system accesses uncompiled software that resides on my machine.

The software access databases that sit on a server upstairs over a network.

Under my limited understanding of the process I believe that when I run an uncompiled program it complies 'on the fly'. The issue is the time it takes to simply open a program, I have all kinds of examples that start up persistent procedures, access the database or simply initialize a screen ready for data entry using both GUI and character based code and all software is slow to open the first time or after a change is made to the source.

I have been to the techies and they have assured me my network point is working fine, the occurrence of this issue coincided with a move of desk(and network point) and a new PC so not 100% on the root cause...

Has anyone out there experienced anything similar or have any ideas as to what I could try to over come this. It is also a problem when it comes to compiling software via the app builder and also using the check syntax option which made me think its possibly related to openedge.

My machine is a 64bit machine running windows 7 and I'm using openedge 10.2b service pack 3.

 

[Cringer]

No idea how sensible a course of action this is, but how about getting a list of all the servers that you're having to access for db and/or code access and pinging them to see if any are a weak link?

 

[stokefc22]

Wow Cringer that was fast... thanks

I shall try this, one thing I forgot to mention is that other developers don't seem to experience this issue if your suggesting that a server is a weak link would you not expect it to effect them too??

As I said my knowledge is less than limited on this

 

[RealHeavyDude]

Compiling source code, or course depending on how many database objects are referenced in it, needs loads of information from the database and produces loads of database hits. You can avoid this to have to go over the network in providing a local schema cache - but at that point I have to admit that I never used it.

Anyway, since the problem is only occurring on your machine I suspect that there isn't something wrong in general with the network - but with how your machine gets to the server. First I would try to rule out a routing problem. You can compare the output of the tracert command from your machine against one from a machine where the issue does not occur. It they are not identical then you have a routing problem.

Next I would check what has changed on your machine besides moving it to another desk.

Heavy Regards, RealHeavyDude.

 

[Cringer]

How about connecting your computer to the a network point from a colleague's machine that you know works and see if that resolves the issue?

 

[Rob Fitzpatrick]

OK so rightly or wrongly(no hope of a change!!) we have a 'development environment' setup on our local machines where our system accesses uncompiled software that resides on my machine.

The software access databases that sit on a server upstairs over a network.

So to summarize, for a given developer, they run the ABL client on their own PC ("machine A") which connects to databases on a server ("machine B") and pulls source code from your personal Windows 7 PC ("machine C"). You haven't specified what platforms machines A and B are, but regardless this setup does not sound ideal for low application latency and general performance. Essentially machine C is acting as a file server, while simultaneously acting as your development PC (or running whatever other workload you may have).

Don't try to use a client OS for a server role, especially when you already have at least one server available. Put the source code in a shared directory on your server, and have the developers change their propaths accordingly. Alternatively, if you don't want code on the database server and have another server you can use for your code repository, then use that instead.

Under my limited understanding of the process I believe that when I run an uncompiled program it complies 'on the fly'.

Correct.

The issue is the time it takes to simply open a program, I have all kinds of examples that start up persistent procedures, access the database or simply initialize a screen ready for data entry using both GUI and character based code and all software is slow to open the first time or after a change is made to the source.

Moving the code off your PC should help with that.

If you have "techies" at your disposal, use them. Make them prove to you not only that things are good, but how good. Make them show you IO graphs and duration and throughput for file transfers across the network from C to A, and from B to A (and check the propaths to confirm that that is the code path across the network). It's easy for them to say "network is good, must be the <x>", where <x> is something they don't understand or aren't responsible for, like the application or database. It's harder for them to provide actual proof (but it's still pretty easy for them, if they know what they're doing).

 

[andre42]

Hi stokefc22,

I don't know if this helps but here are some observations I made.
In our application compilation speed strongly depends on latency when accessing source files. (The propath usually has a lot of entries and most times are not found before eg. the 10th entry, and we use a lot of includes/libraries so when compiling a single file a lot of other files are accessed.)
So the fastest way to compile (or run the application with on-the-fly compile) is to have all files locally accessible, which we do on developers' machines (using source control) and the deployment servers.
Even switching to a locally mapped network drive (ie. \\localhost\application is mapped to eg. P: ; GUI application so Windows is needed) means that compile times double or even triple. (Compiling the complete application takes about an hour on a current system when configured correctly.)
Using UNC paths is even worse, even when they point to the local machine, more so when they point to a server.
I think using UNC paths pointing to a server means that the total compile time increases more then tenfold compared to local paths.

I remember that compilation on Un*x behaves much better, though.