On 10 Jul 2017, at 00:05 , Ashley Betts <Ashley.Betts at saltbushsoftware.com> wrote:
Oh yes, sorry about that. I originally had screen shots attached showing the timings but the email ended up being too large. All of the time is in the print. Nearly all other commands run within seconds. Oddly, after approximately half hour the prompt returns which I get one Sys.time() to execute but then the prompt hangs when I enter the second Sys.time() for the best part of an hour and half.
I tried to profile but that failed. I tried sampling the process a number of times and every time I sampled execution was buried in CGContextDrawPath
GEPolygon (in libR.dylib) + 127 [0x101cb54df] engine.c:0
+ 2502 clipPolygon (in libR.dylib) + 571 [0x101cb574b] engine.c:1080
+ 2502 CGContextDrawPath (in CoreGraphics) + 181 [0x7fff8d433e59]
+ 2502 ripc_DrawPath (in libRIP.A.dylib) + 417 [0x7fff8ec631a3]
+ 2502 ripc_Render (in libRIP.A.dylib) + 380 [0x7fff8ec4f750]
+ 2502 RIPRenderCoverage (in libRIP.A.dylib) + 1844 [0x7fff8ec4ff84]
Regards,
Ashley
<macplottimes.jpg>
On 9 Jul 2017, at 9:35 PM, peter dalgaard <pdalgd at gmail.com> wrote:
Hmm, you're not telling us much about where the time is being spent. Some more detailed timing using system.time() could be useful.
If it is a graphics device issue, I would expect almost everything in the final print(plt). You could try switching graphics device, e.g. to pdf() which should be pretty much the same on all platforms. You might also try creating PDF files on one machine and displaying on the other.
-pd
On 9 Jul 2017, at 12:45 , Ashley Betts <Ashley.Betts at saltbushsoftware.com> wrote:
Hi All,
I'm quite new to R and recently started investigating the geospatial plotting capabilities of R via ggplot2. I started by using some of the publicly available datasets from the Australian Bureau of Statistics. Plotting the Level 3 Statistical Area boundaries took over 2 hours on my 2012 Mac Book Pro. As there were over 3M rows in the fortify?ed data frame I initially thought this was just how long it must take. I then ran the exact same script on my work laptop which is similarly spec?ed and it ran in approximately 30 seconds. This now has me extremely disappointed in the performance on the Mac which is where I use R the most. I changed my BLAS library to the Accelerate library in a whim that this might make a difference. It did not. Whilst I primarily use RStudio I also ran the same script in R.app and if there was any improvement it was not noticeable. I did notice in the Windows run that it seemed to use multiple cores (which is what made me investigate the BLAS change) whilst the Mac seems to stay bound to a single core. My initial thoughts were that it must be something to do with ggplot but after sampling the rsession process a number of times (see attached Sample of rsession.txt) it appears to be spending most of it?s time in CGContextDrawPath in Apples CoreGraphics so I assume it is a Graphics related issue. I?m running R 3.4 on my Mac and 3.3.2 on the Windows machine. I?ve attached the script and have screen dumps of the process sample text and a number of others which I can supply if helpful in analysing the issue. Could someone possibly let me know if this is PEBCAK issue or an actual problem with R. If the later how do I go about getting the issue resolved?
The SA3 boundary data is available here:
http://www.abs.gov.au/AUSSTATS/abs at .nsf/DetailsPage/1270.0.55.001July%202016?OpenDocument
as 'Statistical Area Level 3 (SA3) ASGS Ed 2016 Digital Boundaries in ESRI Shapefile Format?
Regards,
Ashley
<aus_pop_analysis.R>