system.app very slow

[Nigel Gomm]

using the GDI classes in system.app is very very slow on some PCs and i've been unable to see the difference between them and other PCs where it runs normally.

here is a short extract from a coverage log


87.722426,sfribbonbase,sfribbonbase.init,3,c:\program files (x86)\rentman5\classes\sfribbon.vct,5
58.203741,sfgdimeasurestring,init,73,sfgdimeasurestring.fxp,6
0.000156,xfcsystem,drawing_access,,c:\program files (x86)\rentman5\system.app,7
58.203095,xfcsystem,drawing_access,,c:\program files (x86)\rentman5\system.app,7
0.000090,,system.drawing,,system.drawing.fxp,8
58.201506,,system.drawing,,system.drawing.fxp,8
6.573263,xfcdrawing,init,,system.drawing.fxp,9
0.000048,xfcdrawing,init,,system.drawing.fxp,9
28.416191,xfcdrawing,init,,system.drawing.fxp,9

58 seconds just to "WITH _SCREEN.SYSTEM.DRAWING"

and
0.000009,xfcgdiptoken,initknowncolors,,system.drawing.fxp,11
0.000012,xfcgdiptoken,initknowncolors,,system.drawing.fxp,11
0.000009,xfcgdiptoken,initknowncolors,,system.drawing.fxp,11
0.000007,xfcgdiptoken,initknowncolors,,system.drawing.fxp,11
14.091992,xfcgdiptoken,init,,system.drawing.fxp,10
0.000039,xfcdrawing,init,,system.drawing.fxp,9
0.000027,,system.drawing,,system.drawing.fxp,8
0.000018,xfcsystem,drawing_access,,c:\program files (x86)\rentman5\system.app,7
0.000013,xfcsystem,drawing_access,,c:\program files (x86)\rentman5\system.app,7

and
28.488308,sfgdimeasurestring,init,86,sfgdimeasurestring.fxp,6
0.000013,xfcdrawing,drawing2d_access,,system.drawing.fxp,7
14.727432,xfcdrawing,drawing2d_access,,system.drawing.fxp,7
0.000207,,system.drawing.drawing2d,,system.drawing.drawing2d.fxp,8
14.197795,,system.drawing.drawing2d,,system.drawing.drawing2d.fxp,8
0.005064,xfcdrawing2d,init,,system.drawing.drawing2d.fxp,9
0.000064,xfcdrawing2d,init,,system.drawing.drawing2d.fxp,9
0.000034,,system.drawing.drawing2d,,system.drawing.drawing2d.fxp,8
0.000013,xfcdrawing,drawing2d_access,,system.drawing.fxp,7
0.000012,xfcdrawing,drawing2d_access,,system.drawing.fxp,7
0.000246,xfcdrawing2d,smoothingmode_access,,system.drawing.drawing2d.fxp,7
13.759443,xfcdrawing2d,smoothingmode_access,,system.drawing.drawing2d.fxp,7
0.000188,xfcdrawing2d,smoothingmode_access,,system.drawing.drawing2d.fxp,7

object creation taking 14 secs.

the one PC i can produce this on is an AZURE VM with windows 10. But i'm having reports from one customer that looks to be the same (but not quite as bad).

It's a 30mb .exe so i increased PROGCACHE in case it's memory and paging - but no change. Built without debug info to reduce size to 22mb but again no change.

the system.app is in the same folder as the .exe and i set default to that folder before the DO SYSTEM.APP (so not it's finding a system.app on a network drive).

Just to emphasize..... all runs well on most PCs where this is installed; just the one AZURE VM and one customer network where it is slow. on the customer's network i have tried removing all AV and can see nothing else that might interfere.

any thoughts ?

nigel

 

[tomk3]

Hello,

can you try to run it from a non systemfolder like c:\ohmytest or d:\testit
Regards
tom

 

[Nigel Gomm]

tom,

tried that... no difference.

n

 

[Nigel Gomm]

it's to do with paths.

When i RDP into that VM without the local c drive mapped across the problem goes away.

edit : putting set default to (justpath(sys(16,0))) before the call to system.app solves the problem when the local c drive is mapped. There has to be a better way but at least i know where the problem lies.


The customer experiencing this isn't using RDP so not sure what's going on there.

n

 

[Chris Miller]

Look into system.app. I think in its start code it adds some paths and uses additive SET PROCEDURE and SET LIBRARY, so after initializing DO system.app any code finds what it needs. But it might not be what works on this Azure VM.

In short I think this would be interesting to the gdiplusx developers for a bugfix of system.app, if it is an issue of search precedence that could be handled better.

Chriss

 

[Nigel Gomm]

Chriss,

only seeing SET PROCEDUREs if _VFP.startmode = 0.

...thinking of bring the system*.prgs into the main project and doing away with the .app.

n

 

[Chris Miller]

Hm, that's a bit odd. It's well known you don't need to point to anything included in an EXE, but the app is separate. I know the system.app mainly adds itself to _screen and any further usage is through the object tree generated.

Making it a full part of your own EXE by merging the projects could work. I guess the idea to keep it separate is the same as with the report apps. And foxypreviewer also is successfully initializing by a DO. How about only embedding the systemapp into your EXE in the Code->Applications section and then Do system.app In your.exe or Do system.app IN (sys(16,0)) or even just Do system.app

Maybe a concept that could work more generally. I'll give it a try later.

Chriss

 

[Nigel Gomm]

Chriss,

How about only embedding the systemapp into your EXE in the Code->Applications section and then Do system.app In your.exe or Do system.app IN (sys(16,0)) or even just Do system.app

that's how it was. But it seemed that to create a system.app GDI object vfp was searching the default folder before it searched the .app. And if that default was the local C drive in an RDP session.......

I just tried bringing the .prgs into the main project, doing

do system.prg

instead and it looks like it is working a lot quicker - it just took a second off a form load even on my development PC.

This is using Doug Hennig's Ofice365 ribbon...and that uses system.app GDI functions so each form load was struggling with this.

n

p.s. Vernpace (if you are reading this) you were right - using a ribbon needed much fancier graphics.

 

[tomk3]

Hello,

what about sys(2450,1), its mentioned for procedure search but maybe worth a try.

Regards
tom

 

[Chris Miller]

Hi Nigel,

it would be nice to see where the VFP runtime searches for system.app. And you can with ProcessMonitor.

Without investigating that deeply, the first location of files not embedded in the EXE are in the EXE folder (or Working Directory). It's weird if that takes so long, could it be system.prg within system.app doesn't find files inside the app?

And I forgot you can't embed an APP in an EXE unless you add it to other files. The Code->Application node excludes all app ad fll files you add to a project, I think it only looks for things it doesn't find as or in any project file. Just like adding a DBC to a project helps the compiler to resolve stored procedure calls, meaning not logging an error for an undefined function or PRG.

If you add it to others, it just becomes an included file, but unlike VCXes or PRGs VFP doesn't look for internal APP files to run them. And an inheritence by Classloc won't get redirected to a VCX inside an APP inside your EXE.

Have you tried

DO Justpath(SYS(16,0))+"system.app"

or

DO system.prg IN  Justpath(SYS(16,0))+"system.app"

What is Sys(16,0) run in an EXE on your Azure VM? Is there something related to Virtualization? When the mapped C drive matters, that points out something is searched and that times out without error, but slows down the initialization.

On the other side, it's totally valid to include the PRGs and VCXes from the GDIplusX system.pjx.

Tom, you're absolutely right to point out SYS(2450), I wonder if there is a documentation bug, as it says the default precedence is not within the EXE but "along path and default locations". It's easy to test, let me see...

...In any case the search should be fast in your situation, even if the search begins external but in the EXE folder that's an immediate hit, and if the search starts within embedded files that should also be resolving fast (also for not finding it embedded). So there's something strange when a search wanders into other directories. The circle closes then, when a shortcut to the exe defines a bad Working Directory, see above "EXE folder (or Working Directory)".

Chriss

 

[Chris Miller]

One short thought: Is it perhaps about locating the GDIplus.dll and declaring/using its functions? What about the foreground/background memory SYS(3050) settings? I assume resources are tighter in aVM environment with multiple users, even if a VM can scale by demand on any billionaires host server.

Chriss

 

[Nigel Gomm]

Chriss,

i had moved gdiplus.dll into the same folder as the .exe and .app and yes i did

do (forcepath("system.app",justpath(sys(16,0)))

.

I did play with sys(3050) and PROGCACHE but they didn't seem to affect it... shifted focus to paths when not mapping my local c drive to the rdp session and

SET DEFAULT TO (justpath(sys(16,0)))

before calling system.app classes drastically improved things.

Tom,

i had forgotten about sys(2450) but not sure a separate .app would be included in the "search within the application" ?


That will have to be testing for another day - i've included all the system*.prg s into the main project now and that seems, so far at least, to be much quicker. Usage remains the same... a call to system.prg creates the _Screen.system.drawing object as before.

n