This project is read-only.

Problems with FoxCharts speed

Aug 23, 2010 at 3:20 PM

I am having problems with the length of time it takes for a chart to come up.

My charts has three data series of 52 items each (history by year for three years). The chart is a simple line chart.

On my (fast) development machine, this takes 2.9 seconds to draw.  On a user machine, it takes 20-25 seconds .. miserably slow.

Curiously, it has been this slow for a long time, but no user informed me of it until today.

Thanks in advance,

Jim

Aug 30, 2010 at 5:47 PM

Hi everyone,

I'm having the same problem, I have read post http://vfpx.codeplex.com/Thread/View.aspx?ThreadId=203777 but this post does not resolve any issue. So far in my tests, the machine build is not the problem. My pc is an intel core2duo@2.66 with Win7x64 and 4GB of RAM. In this machine, running my app inside foxpro will give me acceptable times drawing the chart, but if I generate an .EXE and I execute it, the chart is very slow (About 10 seconds to draw a Piechart). Curiously, if I take this .EXE and I run it in a WinXP with an intel P4HT@3Ghz with 1GB of RAM, is faster than my machine. I have seen some posts that suggests that this problem is caused by the gdiplus.dll version, but finally, they don't give any advice of which version of gdiplus.dll is the best for foxcharts and how to make that foxcharts use that version instead of the OS version (Because I haven't been able to remove the gdiplus.dll that comes with win7 because is protected and don't allow me to erase it). I hope someone to give us some advice around this issue. Thanks in advance.

Aug 30, 2010 at 8:09 PM
Edited Aug 30, 2010 at 8:11 PM

Hi,

Would you be able to make use of the Coverage profiler and see which method is making it slow down?

Awaiting your response,

Koen

Aug 30, 2010 at 8:15 PM

I have experienced some serious degradation as well ... and, when I turned on the coverage profiler, the total run time grew by such a multiple that I found it very difficult to isolate which code segment was the culprit.

Unfortunately, while I need to get this resolved, I am not able to contribute anything more to the discussion at this time -- but I too am watching this discussion very closely, and hope that something can be done.

Aug 31, 2010 at 6:19 PM

Hi everyone,

 

I've tried coverage profiler only shows me excesive time consumption in drawchart() method of foxcharts but I think is not an useful data since the coverage profiler ask me to evaluate system.app source code but is not available. I'll try to get a more detailed info from the coverage profiler. Thanks in advance.

Sep 2, 2010 at 1:46 PM

I have add some success in isolating the culprit line of code:

Method    ._DrawShape, line 47:        loRect = loPath.GetBounds()

This line is executed once for each point appearing on a chart.  In my just concluded sample, it took 15.32 seconds for 162 iterations -- that is, almost 1/10th of a second each.

Hoping this helps

Sep 7, 2010 at 10:20 AM

Hi,

 

I noticed you face a problem to analyze the code produced by the coverage profiler, maybe the application developped by Maurice de Beyer can assist you to analyze the code. Maurice's codeanalyzer can be downloaded at : http://www.theproblemsolver.nl/downloads_vfp.htm#Coverage%20anayzer

 

Regards,

 

Koen

Sep 27, 2010 at 4:11 PM

Hi Koen and Jim,

Fortunately, we'll meet in person in 15 days :-D

I truly could not reproduce the problems related. I have it working here since 2 years, and this has never happened in my environment. It would be glad if one of you could take with you a sample reproducing the issue, so that I can make the needed adjustments. I suspect that this is related to gdiplus.dll, NOT FoxCharts or GdiplusX library, but I need to reproduce the problem to be sure of that.

Regards

Sep 27, 2010 at 5:29 PM

Howdy --

This may or may not be related ....

A user today got an error in the following file:          

C:\USERS\BDURBAN\APPDATA\LOCAL\TEMP\SYSTEM.DRAWING.FXP

Any idea where THAT could come from, or why it would be executing something from BDURBAN ??????

Sep 27, 2010 at 5:58 PM
Edited Sep 27, 2010 at 6:05 PM
jimrnelson wrote:

A user today got an error in the following file:          

C:\USERS\BDURBAN\APPDATA\LOCAL\TEMP\SYSTEM.DRAWING.FXP

Any idea where THAT could come from, or why it would be executing something from BDURBAN ??????

Hi Jim,

It seems that you are using the GdiPlusX version released by Bo Durban, and not mine. I did all the work with FoxCharts with a previous release of GdiPlusX. You can see in the codes of FoxCharts that there are some direct API calls inside, because some functions were not available at the current official release.

Anyway, this should not be an issue at all ! I just kept with an old version to make sure that all users would be able to keep using FoxCharts, even if they had an old release of GdiPlusX.

Please do the following test:

Download the latest version of FoxCharts again, and use the System.App version that you will find there.

Let me cross my fingers... who knows ? Maybe we found the source of our problems ?

Sep 27, 2010 at 6:20 PM

Hmmm ... The only version of system.app that I can find (on my own machine) is in my path, 820K, dated 5/25/2009 5:47 pm.  This is the most current file, isn't it? .... and its slow for me as well.

Is there any way, when the app is executing, to learn what version of gdiplus.dll and system.app are being used?

 

 

Sep 27, 2010 at 9:18 PM

Howdy

I have downloaded the latest version of FoxCharts and verified that I am using that version of SYSTEM.APP (actually, I renamed it to SYSTEMNEW.APP -- and then looked at _Screen.System.ClassLibrary).

Nothing changed, the chart still takes about 20 seconds to come up.

Earlier messages referred to GDIPLUS.DLL.  I find many such files on my machine, and on users' machines (I can't get to their machines directly, since I am not at the site). 

How in the world am I supposed to know which one is being used?  Eliminating other copies from a user's machine seems like the wrong approach -- how in the world can I know that such an action would not cause something else to fail?

Cheers from sunny (and hot) So. Cal.

Sep 27, 2010 at 9:50 PM
jimrnelson wrote:

How in the world am I supposed to know which one is being used?  Eliminating other copies from a user's machine seems like the wrong approach -- how in the world can I know that such an action would not cause something else to fail?

Jim,

I truly don't know for sure. Let me tell you about a problem that we had 3 years ago, when we started coding GdiPlusX.

In some API declarations we used:

DECLARE LONG GdipFunction IN GDIPLUS 

in other places, we had:

DECLARE LONG GdipFunction IN GDIPLUS.DLL

The only difference was the ".DLL" file extension !!! Believe me my friend, this brought lots of issues IN THE GRADIENT IMAGE GENERATION ! We had to force always the use of the ".DLL" to solve these problems. I just know that when you run in development, VFP knows exactly what version to use. Running from the EXE... I can't be sure of what DLL version it will use for sure. I confess that I did not make too many testings.

Another thing that I wanted to know is if the speed issue happens with all kinds of charts. I presume that Bar charts, with solid colors will not have this issue, right ? maybe only with gradient colors ? Or only with Pies or Doughnut charts ???

Sep 27, 2010 at 9:55 PM

The only charts being used are line charts.

Nothing else.

Is it possible for there to be an alternative definition of SYSTEM.APP which refers to a different DLL?    GDIPLUS2.DLL or something like that, and the correct DLL could be renamed to GDIPLUS2.DLL?  (Yes, I am grasping here -- but my users are avoiding FoxCharts precisely because of this issue.)

Sep 27, 2010 at 9:59 PM

Ok Jim,

Does the speed issue happen in your computer as well ? I need to see the problem only once, to be able to find the issue... Or if you could just check in one of those client machines...

Anyway, I PRESUME that it could be possible to rename GDIPLUS.DLL to another name, and change the API declarations in GdiPlusX to point to that file.

Sep 27, 2010 at 10:48 PM

Jim,

One other thing...

The Line charts use some shapes in the intersection points. These are created using the GraphicsPath classes. Please tell your users to use VCD and remove those intersection shapes. Tell me if it goes fast again, please !

Sep 27, 2010 at 11:39 PM

I do NOT have this problem on my local PC.

On my customer's LAN, however, it does occur, both to me (I log in using Citrix) and to the local users.

Sep 27, 2010 at 11:41 PM

RE: Points at intersection points.

Yes, in fact, removing the intersection points makes for an essentially instantaneous chart.  So, presumably, what is generating those pesky little points is the root of the problem.

 

Sep 27, 2010 at 11:47 PM
jimrnelson wrote:

RE: Points at intersection points.

Yes, in fact, removing the intersection points makes for an essentially instantaneous chart.  So, presumably, what is generating those pesky little points is the root of the problem.

 

Ok Man !

Only YOU could make me reopen those sources, hehehehe. Let me check this thing later. Could you send them any other sample version of some other charts different from LINES ? There is a fantastic tool called VCD that would make shifting to other kinds of charts very simple ! I'd like to have more details about this...

It is possible that the intersection shapes work with solid colors, Please provide more tests !

 

 

 

Sep 28, 2010 at 12:00 AM

Cesar --

Well, the only chart that matters IS lines, since that's the only kind the user wants.

The data being presented is three series of 52 data points each ... history by week for the last 52 weeks.  The line chart is clearly the best way to present this data.  (There are so many columns that the bars in bar charts are only a few pix wide, so its not very pretty.

I am not sure about your reference to intersection shapes and solid colors.

So far, performance is just miserable if I turn on Line Caps, regardless of which ones I select to display ... an (close to ) instantaneous if I turn off Line Caps.  (I find the lines without line caps to be quite unappealing)

Sep 28, 2010 at 12:05 AM

Ok Jim,

But this problem reinforces my guess that the problem is with gdiplus.dll. Later I'll call you directly. I'll try to prepare a new version for you to test, probably using other commands of Gdi+

The reason that I asked you to go further with the tests is because I want to create a definitive solution for this. I need to know exactly what chart types or features make the problem to appear. Gdi+ offers different ways to reach some goals, I could try to find or create a new technique for those caps, but what about the other chart types ? I'm asking you just to run VCD in one of these machines and tell me what chart types show the problems and what go smooth.

Thanks in antecipation !

Sep 28, 2010 at 12:29 AM

Cesar:  Timings

  • Pie                        1.33
  • Dougnut              20.24
  • Single Bar              0.56
  • Horz Single Bar      0.56
  • Point                    26.30
  • Line (Caps)           17.44  
  • Line (w/o Caps)      0.39
  • Mult Bars               0.83
  • Stacked Bars          0.83
  • Full-Stacked           0.86
  • 3D Bars                 0.84
  • Area                      1.05
  • Stacked Area          0.45
  • Full-Stacked           0.56

Hope this helps

 

Sep 28, 2010 at 12:34 AM
Edited Sep 28, 2010 at 12:36 AM
jimrnelson wrote:

Cesar:  Timings

  • Dougnut              20.24
  • Point                    26.30
  • Line (Caps)           17.44  

Hope this helps

Hi Jim,

THANKS SO MUCH !

For sure that helps ! Can you make some other testings, please ? I'd like you to find a configuration when the Doughnut chart works. Please try with different color types, gradients, solid colors, etc. I'd like to know if Doughnuts could work somehow. That is the KEY for the solution, even for the line chart caps, believe me !

I know it's painful to wait for 25 seconds for a sample to run. It should run faster if you select the "depth - 3D effect" to 0 (zero maybe) ?

Thanks dude !

Sep 28, 2010 at 12:47 AM

I tried just about every combination of .ColorType and .BrushType I could --- no real change (variations of a second or two ...)

As for depth, it's been zero for all my tests.

Sep 28, 2010 at 12:48 AM

Incidentally, a pie or doughnut chart with that many colors is quite impressive.  Psychedelic indeed, if it could only spin! (or pulse).

Sep 28, 2010 at 2:26 PM

LOL !

Pie/Doughnut charts are not indicated for such big data :-D

Thanks for your testings !

Sep 28, 2010 at 2:45 PM

Hi guys, I've been following this thread closely because I'm affected too with this issue. I can't actually do as many accurate tests  as Jim due to tasks in my job, but so far the summary of my tests are as follows:

In a Win7 x64 machine (my development machine), I haven't been able to encounter why my charts (specially pie and dougnut) draws so slow when running my .EXE. If I run it in foxpro without compiling it, the speed increases. (I don't know if Jim have done this type of test). The thing that makes me think about the gdiplus.dll version is the fact that if I take the same .EXE and I run it in a winXP x86, the speed is increased noticeably, although is not that fast as when I run it in development mode without compiling the .EXE.

The fact that the samples included with the foxcharts package run smoothly both in development mode and compiled in an .EXE in my dev machine makes me think about if there is a "SET" property or another configuration in my app that can affect the perfomance of the class. (Difficult to know so far)

Although the data of my app don't use foxpro tables (I use SQLServer 2005/8), I transfer the resultset to a temporary foxpro table to assign it to the chart data source, so I don't think this causes a difference.

The fact of changing depth to 3d effect doesn't affect noticeably the speed, but the quantity of slices of a pie for example affects the drawing time although my pies don't have more than 12 slices.

I hope I can take more time to do tests. Thanks you for your help.

Sep 29, 2010 at 7:14 PM

Thanks Hotaru,

Just an update to those who are following this discussion. Yesterday I received some important information about the speed issue in certain Charts (doughnut, points and lines). I managed to fix the Points and Lines problems. The status now is that I want to wait for a couple of days and see if Jim approves that release. If positive, I'll create a new release and make it available to everybody.

If you face any problem with doughnut charts, please avoid using this chart type for a while, till I manage to find a definitive fix, or a faster technique to make those drawings. Please use PIE CHARTS instead.

Sorry for the inconvenience, and thanks for all the testings, specially to Jim Nelson.

Nov 15, 2010 at 8:41 PM

Hey folks. I'm starting to have performance issues as well, but with simple bar charts. When running through the debugger, DrawChart executes very quickly. However, at runtime it takes much longer - at least 15 seconds.

I did some research with the coverage profiler, and I think this might be the culprit:

xfcimagecodecinfo::_getendecoders line 6563

Any ideas would be greatly appreciated.

Nov 18, 2010 at 10:05 PM

Well, it turns out that the issue was a huge SET PROC list. The combination of cleaning up the proc list and clearing it before chart rendering brought it down to 1 second.

Feb 6, 2011 at 9:15 AM

Hi to everyone! I'm experiencing the same problem on line charts. Each charts has 4 series, 3 with approx 20-30 values, the 4th with only one value.

On production machine the speed is about 4-5 sec. on the server, while launching from clients, it took about 50-60 sec. to draw the chart.

The values of the chart are in a memory cursor created on the server machine. Does anybody fixed this problem?

Let me know, otherwise I cannot release the application to my customers.

Client is a core duo with xp sp2 and 3gb ram.

 

please help!

cirollo