Hi Peter, outputting to PDF made a huge difference! It ran for only 15 seconds and there was no trailing unresponsive prompt. The PDF ended up being around 2Mb and opened and displayed almost immediately in Preview.
I did watch the system when I was outputting to the quartz device last time and the process was steadily consuming a single core. When I watched it on the Windows machines I saw it use most of the cores but not to capacity. After seeing this I read up on multithreading libraries on Mac and finally setup R to use the Accelerate library. I’ve verified this library is being loaded by sampling the process. It make zero difference however and the print(plt) still only consumes a single core. Regards, Ashley > On 10 Jul 2017, at 6:21 PM, peter dalgaard <pda...@gmail.com> wrote: > > Pretty clear that the process is getting stuck in Apple-graphics land, then. > This could be inefficiency of the device driver, but also just ... Apple. > Could you try running the same thing to a PDF (AFAIR, just open the device > with pdf(file="myplot.pdf"), then print(plt), then dev.off()). It would be > good to know if this is fast, and also whether viewing the resulting PDF in > Preview is slow (in which case it is Not Our Problem). > > Also, does running the Activity Monitor give any clues? Like, perhaps you are > running out of memory. > > -pd > >> On 10 Jul 2017, at 00:05 , Ashley Betts <ashley.be...@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 <pda...@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.be...@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@.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> >>>> >>>> >>>> >>>> _______________________________________________ >>>> R-SIG-Mac mailing list >>>> R-SIG-Mac@r-project.org >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >>> >>> -- >>> Peter Dalgaard, Professor, >>> Center for Statistics, Copenhagen Business School >>> Solbjerg Plads 3, 2000 Frederiksberg, Denmark >>> Phone: (+45)38153501 >>> Office: A 4.23 >>> Email: pd....@cbs.dk Priv: pda...@gmail.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> Ashley Betts >> >> Saltbush Software >> Excellence in Software Engineering Practices >> >> email: ashley.be...@saltbushsoftware.com >> ashley.be...@sbsw.com.au >> web: http://www.saltbushsoftware.com >> http://www.sbsw.com.au >> > > -- > Peter Dalgaard, Professor, > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Office: A 4.23 > Email: pd....@cbs.dk Priv: pda...@gmail.com > > > > > > > > > Ashley Betts Saltbush Software Excellence in Software Engineering Practices email: ashley.be...@saltbushsoftware.com ashley.be...@sbsw.com.au web: http://www.saltbushsoftware.com http://www.sbsw.com.au [[alternative HTML version deleted]] _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
