This project is read-only.

FoxCharts 1.20 - extreme slow piecharts

Topics: Bug Information
Mar 4, 2010 at 11:58 AM
Edited Mar 4, 2010 at 12:13 PM

Hi everyone,

i was having show-stopping-trouble with FoxCharts 1.20 when displaying stats as pie-chart. As i finally found the reason / solution i want to share my experiences with you so nobody needs to waste lots of workhours to find out what's going on.

Problem:

When (and only when) charttype = pie the drawing of the pie takes "forever". Compared to "instant" drawing with all other charttypes, pies take from 2 to 10 seconds (depending on hardware/ram-situation). As a horrible side-effect a manual form-resize by mouse is so slow that it takes up to 10 seconds until the form shows up in it's new size (assuming the foxchart-object is anchored and wants to resize with it). Usage of the great "click-on-slice"-effects of FoxCharts is impossible even with only 3 or 4 steps used. All in all, pies are simply not usable in this situation.

And important: Alle none-pie-chart charttypes work perfectly fine and show instant results when DrawChart() is called.

The question is: What is causing the horrible delays?

Test and Environment:

All these tests are made with very simple sample-data derived from our customer data by selecting gender into a cursor (male, female, unknown). So the cursor feed into foxcharts has 3 rows and 3 columns (value1, label1, color1).

All tests were also verified by an EXE-based version of the foxcharts-sample that it is not "our" code in general. Unfortunately the samples showed the very same behaviour when displaying pie-charts.

I tried to hunt this problem down and have found the following facts / points:

  • different hardware / OS make no difference:
     i7 920@2.67, 6GB RAM, Vista Business SP1 (64bit)
     i7 920@2.67, 6GB RAM, Win7 Pro (64bit)
     Core2 E7400@2.8, 4GB RAM, Vista Business SP1 (32bit)
     Dual-Xeon E5430@2.66, 8GB RAM, Server 2008 SP2 (64bit)

The only difference between the machines is the length of time-drag it takes to draw. The dual-xeon powered server takes fewer seconds than the rest, but it's still more than 1 second.

  • on all machines it makes no difference if UAC is enabled or dissabled
  • normally the source-dir is a serverbased directory used through a regular driveletter-mapping (not pure-UNC) and the exe is also run from there.
  • it makes no difference if run from IDE (do test.exe) or run from explorer by doubleclicking test.exe
  • foxcharts-sample show absolut the same behaviour with a "can-be-seen-and-felt-by-everyone"-difference when displaying as charttype=1 (no difference between IDE and runtime-based-EXE)
  • gdiplus.dll
    In general we have always a gdiplus.dll right beside the system.app. As the DECLAREs in gdiplusX are all without a path in my understanding the DLL right beside the system.app is taken to be called. I changed and tested with several different gdiplus.dll - versions. I also tested if it's a difference between side-by-side DLL and none-by-side DLL (aka using local system gdiplus.dll). ...no difference in behaviour.

    gdiplus.dll used versions
    5.1.3097.0000 (was local on fully patched Win7)
    5.1.3102.1360 (what we used to have side-by-side in dev)
    5.1.3102.3352 (latest after last fall security update)
    5.1.3102.5581 (newest i could get my hand on)


Running SET COVERAGE TO for getting a grip on who's wasting my time
After filtering the coverage-output to lines using only more the 0.1 seconds there were quite a few lines with time up to nearly a full second. What became pretty clear after analysing the results is that it was not the VFP code in general that was taking time, but calls within _drawslice burned the seconds away. The more slices a pie has, the longer the drag is, due to the SCAN/ENDSCAN loop.

Main-Burner inside _drawslice were

Line  19: 0.83 sec : This._PrepareBrushes(...)
Line 288: 0.58 sec : loBmp.ApplyColorMatrix(poClrMatrix)

...and surrounding theses are quite some other lines with times up to 0.2 seconds. So each slice is taking time far "inside" the range of felt slowlyness.


To make a long story short: Drilling down the classes down to the DLL-Calls showed that in the end it actually is the call to the gdiplus.DLL-methods that takes so long. Quite perplex i took a last test (why am i testing something obvious as last...)

Copying the complete DEV-tree (with EXE, system.app etc.) from the netfolder to a local folder and starting the already compiled EXE in that local (!) folder.

Result: Perfect behaviour with enough resource-overhead that the foxchart is redrawn and shown even during form-resize.

Using the very same EXE on a netbased folder with netbased system.app etc. gives the horrible delay effect.

What's next?

I don't know. I have absolutely no idea why this situation occurs. The gdiplus.dll was (in my final tests) always local and once DECLAREd i assume the DLL to be in memory. It obviously makes a difference where the calling VFP-Code is actually started from. As the VFP runtimes (or IDE-files) are always local i cannot figure out why this is actually happening.

As this is reproducable on several machines with different EXEs and in different scenarios i would be glad if somebody could verify if this happens to you too. Fortunately our application is intended to be installed locally with only DATAs netbased so it is only "ugly" in my dev-situation. But others may not be so lucky and will find this information helpful.

Feel free to contact me if we want to test this "thing" a little bit further. ...or if you have a reasonable explanation of what's actually happening here.

Happy bug-hunting and best regards
Michael Schwing
from LOGO Datensysteme

Mar 4, 2010 at 2:06 PM

Hi,

do you also experience a slow performance when dealing with the sample forms? If not would you than be able to zip the data cursor for me to test?

Thanks,

 

Koen

Mar 8, 2010 at 1:47 PM

Hi Koen,

sorry for taking so long. post-reply-email got lost somewhere...

Yepp, the generic sampleform shows similar behaviour when compiled into an exe. If i start that exe from a driveletter mapped to one of our NAS it is slow when displaying pies. The very same exe copied to a local drive does not show this behaviour.

The DataCursor which i used is VERY simple ;-)

create cursor crsGraf (label1 c(20),value1 i)
insert into crsGraf values("male",5)
insert into crsGraf values("female",2)
insert into crsGraf values("not selected",1)

oChart.ChartsCount = 1
oChart.ChartType = 1
oChart.Depth = 30
oChart.AlphaChannel = 150
oChart.FieldLegend = "label1"
oChart.Fields(1).FieldValue = "value1"
oChart.Fields(1).Legend = "label1"
oChart.BrushType=2
oChart.GradientShapeDirection=1
oChart.PieEnhancedDrawing=.T. 
oChart.DrawChart()

Hope this helps. If you need something more, i'll be happy to help.

Just stumbled across something missing in _preparesidelegend and trying to fix it. if ChartsCount>1 and assigning different Fields(n).Legend one should expect that here also columns from the sourcetable is meant. But the value of .Fields(n).Legend is just "transformed()" and not "evaluated()". When i changed that, it showed pretty quick that theses Legends are not SQLed into the Temp-Cursor during _preparedata and therefore are not available during _preparesidelegend. I am working on a fix and will offer it soon under a new thread.

For the time being this piechart-runtime-anomaly is not a showstopper for me anymore, because it is not the normal usage scenario for our customer as we are explizitly tell them to install locally.

Regards,
Michael

 

 

 

Mar 8, 2010 at 8:44 PM
Edited Mar 8, 2010 at 8:51 PM

Hi,

quote

Yepp, the generic sampleform shows similar behaviour when compiled into an exe. If i start that exe from a driveletter mapped to one of our NAS it is slow when displaying pies. The very same exe copied to a local drive does not show this behaviour.

unquote

 

Logo, this is not correct behavior, when I run the sample form PieChart in development or in exe it is shown within  < 1 second. If you  confirm piecharts are running localy normally fast but on your NAS slow, I would suggest you to  look into that connection. Be sure to have on both situations same conditions - same FoxCharts / same GDIPlus etc. etc,

Regards,

 

 

Koen

Mar 10, 2010 at 10:41 AM

Hi,

Nope, it's definitely not the connection (runs perfect).

Perhaps i have not made it clear enough in the first post. A connection problem could not be the cause, because most part of the source is just running fine without any trouble (proofed with codeprofiler) but just very specific parts (as detailed in first post). ...and btw. the "NAS" is a dual-xeon based DELL Storageserver and the connection is a dedicated gigabit conn via a managed switch, so no worry about problems on that part... ;-)

Local
VFP.IDE + Runtime.DLLs
VFP started on local PC

Net
sourcecode-Directory with Project and Sourcefiles

This combinations runs slow. If i copy the sourcecode-directory to a local drive and use it from there it runs perfectly well.

...and yepp, i have checked and made sure that VCX / GDIPlus is always the same (also already descriped in first post) so it is also not a problem from that side.

I am still digging arround in the sources so i'll keep you informed if i'll find something.

Regards,
Michael

 

Mar 10, 2010 at 10:27 PM

Michael,

I do understand, sofar,:

1. you are running FoxCharts Charttype1 in sample form on your local pc without any problem.

2. you are running same Chart, same  conditions on an other configuration (NAS) and now only this Charttype running slow, others running fast as they should.

You also tell us it could not be the NAS configuration which may caused this behaviour.

For the time being I dont have an advise for you where to look elsewhere how to solve but I am very triggerd to learn.

Regards,

 

Koen

 

Mar 11, 2010 at 9:24 AM

Hi Koen,

yepp, that wraps it up pretty good. And yepp, i don't see any solutions right now too. As i said: it's not a showstopper because our customers are required to run it locally anyway.

This whole thread was meant as an info for other users experiencing similar behaviour. I saw e.g. http://vfpx.codeplex.com/Thread/View.aspx?ThreadId=77262 where Soione reported problems with execution times. At that time i thought "can't be..." ...until it struck me too.

So please take this post more as a heads-up and not as a bugreport.

I worked through the whole codesegment with debugger and profiler in different scenarios and despite calling myself pretty experienced with nearly 20 years of fox programming under the belt, i couldn't find any reasonable explanation to why it behaves this way. I am ready to say it's an anomaly in this specific scenario and it's not code-specific. It must be something with gdiplus, windows and the place from where the code is run, as it is reproducable on different machines, with different servers AND on totally different net-infrastructures (different net/workplace). So it must be something general and not specific to my personal pc, cable, server etc.

BUT: Run the code locally and everything is working great and without problems!

...and so that nobody get's it wrong: FoxCharts is one of the best pieces of VFP software in a very long time. Locally it is lightning fast and we all love it here at LOGO because in a time when more and more customers ask "Fox what?" this thing is a very good show-off when arguing about "speed". Analyizing data with a complex SQL and displaying the results in a nice looking FoxChart in realtime instead of seconds or minutes shows perfectly the ability of FoxPro in terms of speed. These demos are always a showwinner. :-)

As i am currently converting the whole statistics area of our program to a foxchart-based mask, i am altering / advancing FoxCharts in different aspects.
Smaller ones (like translating error-msgs to German with #defines ) or bigger ones like the missing eval() / temp_cursor-column for the .fields(n).Legend ...

My question now: I would like to offer the work done on that for re-intregration into the official FoxChart. How and where should i post it / send it to?

I am working with Fox since the early days of Fox Software (FPD 2.0) so i would really be glad to give back something to the community.

Thanks and best regards
Michael

Mar 11, 2010 at 2:47 PM

Michael,

Hi FoxCharts is Cesar Chaloms department, also others have done considerable contributions to this project, all listed in the Relevant information for the current release - FOXCHARTS 1.20 PRODUCTION RELEASE to be found in "FoxCahrts_1,20_Production.TXT" a ReadMe.txt file.

My role in this project is only minor: reviewing the Help.chm.

Once upon a time I had started a project to built a FoxChartTemplateHelper in the same time correcting minor cosmetique errors on the main presentation screen. This job meanwhile still unfinished and put back for other jobs. Maybe it is time to startup again and implent your translation Defines. You could contact me on koen_pillerAThotmailDOTcom. For any changement and or enhancement to FoxCharts.vcx you should contact Cesar always.

Regards,

Koen

 

Jul 1, 2010 at 3:43 AM

I have the same problem, but I'm running mine locally.  It is in a Win7 VM on a MacBook Pro using VMWare Fusion, but I find this VM to be quite fast.  Not sure if there is a relationship there, just mentioning it.  Haven't tried other chart types, but I could.  However I need a pie chart, so I'd like to find the solution.  Pie chart takes 6+ seconds to create.

Nov 17, 2012 at 10:43 AM
Edited Nov 17, 2012 at 10:43 AM

I noticed that the method _setup and _Updatemeasure is called several times, in particular the method which is very slow is MeasureString.
Replacing the call MeasureString with a method FOX, less precise but faster, the coverage indicates a decrease in average redraw the image to be 22.xxx to 6.xxx
It's not much but it is a starting point
Now I start to study these cakes are very slow
This tool is very nice try to make it go as fast as the wind
PS: A solution to speed it would, you might think to create a library minimalist call APIs directly without using system.app in gdiplus.dll which is really slow
What do you think?
See you soon