Skip to content

Performance (speed) of ggplot

4 messages · Christopher Battles, Jeff Newmiller, PIKAL Petr +1 more

Original
Christopher Battles
# 
Hello list,

I have been working on learning ggplot for its extraordinary flexibility compared to base plotting and have been developing a function to create a "Minitab-like" process capability chart.  

*sigh* some of the people I interface with can only understand the data when it is presented in Minitab format

The function creates a ggplot container to hold 10 ggplot items which are the main process capability chart, a Q-Q plot, and the text boxes with all the capabilities data.  When I run the function, the elapsed time is on the order of 3 seconds, the gross majority of which is user time.  sys time is very small.  A bit of hacking shows that the calls to 

gt1 <- ggplot_gtable(ggplot_build(p)), 

etc., each take on the order of 1/3 of a second. These times are on a 3.2GHz Xeon workstation.  I'd like to see the entire function complete in less than a second.  My questions are: 1) Am I misusing ggplot, hence the performance hit? 2) Is there any way to increase the speed of this portion of the code? 3) Am I simply asking ggplot to crunch so much that it is inevitable that it will take a while to process?

To that end, the function, vectis.cap(), can be downloaded from http://pastebin.com/05s5RKYw .  It runs to 962 lines of code, so I won't paste it here.  The offending ggplot_gtable calls are at lines 909 - 918.

Usage:
vectis.cap(chickwts$weight, target = 300, USL = 400, LSL = 100)

Thank you,

Christopher Battles
Jeff Newmiller
# 
You are asked in the Posting Guide to provide a small, reproducible example. Your function is Byzantine, and depends on who knows what, and I can't even see what your end product is intended to be.

I will say that I think you have missed the point with your approach to using ggplot... you might well do better with base graphics if coding each display element is necessary for your application.

ggplot is intended for a data-driven approach, where you set up data frames that contain the bulk of your graphic information, and then you should rarely need more than one call for each type of graphic element in a given plot.

That said, ggplot can be noticeably slow sometimes, so I cannot predict whether you will achieve your stated speed goal by reconfiguring the code at this point.
---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
--------------------------------------------------------------------------- 
Sent from my phone. Please excuse my brevity.
On September 25, 2014 11:30:08 AM PDT, Christopher Battles <CBattles at startllc.com> wrote:
PIKAL Petr
# 
Hi

I will second Jeff. If you want several plots on one page it could be more convenient to use standard plot.

see
?layout or ?split.screen
for complex figures

or ?par mfrow

for simple layout.

In all cases it is difficult to combine base and grid graphics though.

Regards
Petr
________________________________
Tento e-mail a jak?koliv k n?mu p?ipojen? dokumenty jsou d?v?rn? a jsou ur?eny pouze jeho adres?t?m.
Jestli?e jste obdr?el(a) tento e-mail omylem, informujte laskav? neprodlen? jeho odes?latele. Obsah tohoto emailu i s p??lohami a jeho kopie vyma?te ze sv?ho syst?mu.
Nejste-li zam??len?m adres?tem tohoto emailu, nejste opr?vn?ni tento email jakkoliv u??vat, roz?i?ovat, kop?rovat ?i zve?ej?ovat.
Odes?latel e-mailu neodpov?d? za eventu?ln? ?kodu zp?sobenou modifikacemi ?i zpo?d?n?m p?enosu e-mailu.

V p??pad?, ?e je tento e-mail sou??st? obchodn?ho jedn?n?:
- vyhrazuje si odes?latel pr?vo ukon?it kdykoliv jedn?n? o uzav?en? smlouvy, a to z jak?hokoliv d?vodu i bez uveden? d?vodu.
- a obsahuje-li nab?dku, je adres?t opr?vn?n nab?dku bezodkladn? p?ijmout; Odes?latel tohoto e-mailu (nab?dky) vylu?uje p?ijet? nab?dky ze strany p??jemce s dodatkem ?i odchylkou.
- trv? odes?latel na tom, ?e p??slu?n? smlouva je uzav?ena teprve v?slovn?m dosa?en?m shody na v?ech jej?ch n?le?itostech.
- odes?latel tohoto emailu informuje, ?e nen? opr?vn?n uzav?rat za spole?nost ??dn? smlouvy s v?jimkou p??pad?, kdy k tomu byl p?semn? zmocn?n nebo p?semn? pov??en a takov? pov??en? nebo pln? moc byly adres?tovi tohoto emailu p??padn? osob?, kterou adres?t zastupuje, p?edlo?eny nebo jejich existence je adres?tovi ?i osob? j?m zastoupen? zn?m?.

This e-mail and any documents attached to it may be confidential and are intended only for its intended recipients.
If you received this e-mail by mistake, please immediately inform its sender. Delete the contents of this e-mail with all attachments and its copies from your system.
If you are not the intended recipient of this e-mail, you are not authorized to use, disseminate, copy or disclose this e-mail in any manner.
The sender of this e-mail shall not be liable for any possible damage caused by modifications of the e-mail or by delay with transfer of the email.

In case that this e-mail forms part of business dealings:
- the sender reserves the right to end negotiations about entering into a contract in any time, for any reason, and without stating any reasoning.
- if the e-mail contains an offer, the recipient is entitled to immediately accept such offer; The sender of this e-mail (offer) excludes any acceptance of the offer on the part of the recipient containing any amendment or variation.
- the sender insists on that the respective contract is concluded only upon an express mutual agreement on all its aspects.
- the sender of this e-mail informs that he/she is not authorized to enter into any contracts on behalf of the company except for cases in which he/she is expressly authorized to do so in writing, and such authorization or power of attorney is submitted to the recipient or the person represented by the recipient, or the existence of such authorization is known to the recipient of the person represented by the recipient.
ONKELINX, Thierry
# 
You are using ggplot2 very inefficiently. Many geom's plot only one data point. You can combine several of them in a single geom. Have a look at this gridExtra package which has some useful functions like grid.arrange and tableGrob.

Best regards,

ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature and Forest
team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium
+ 32 2 525 02 51
+ 32 54 43 61 85
Thierry.Onkelinx at inbo.be
www.inbo.be

To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of.
~ Sir Ronald Aylmer Fisher

The plural of anecdote is not data.
~ Roger Brinner

The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey

-----Oorspronkelijk bericht-----
Van: r-help-bounces at r-project.org [mailto:r-help-bounces at r-project.org] Namens Christopher Battles
Verzonden: donderdag 25 september 2014 20:30
Aan: r-help at r-project.org
Onderwerp: [R] Performance (speed) of ggplot

Hello list,

I have been working on learning ggplot for its extraordinary flexibility compared to base plotting and have been developing a function to create a "Minitab-like" process capability chart.

*sigh* some of the people I interface with can only understand the data when it is presented in Minitab format

The function creates a ggplot container to hold 10 ggplot items which are the main process capability chart, a Q-Q plot, and the text boxes with all the capabilities data.  When I run the function, the elapsed time is on the order of 3 seconds, the gross majority of which is user time.  sys time is very small.  A bit of hacking shows that the calls to

gt1 <- ggplot_gtable(ggplot_build(p)),

etc., each take on the order of 1/3 of a second. These times are on a 3.2GHz Xeon workstation.  I'd like to see the entire function complete in less than a second.  My questions are: 1) Am I misusing ggplot, hence the performance hit? 2) Is there any way to increase the speed of this portion of the code? 3) Am I simply asking ggplot to crunch so much that it is inevitable that it will take a while to process?

To that end, the function, vectis.cap(), can be downloaded from http://pastebin.com/05s5RKYw .  It runs to 962 lines of code, so I won't paste it here.  The offending ggplot_gtable calls are at lines 909 - 918.

Usage:
vectis.cap(chickwts$weight, target = 300, USL = 400, LSL = 100)

Thank you,

Christopher Battles

______________________________________________
R-help at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
* * * * * * * * * * * * * D I S C L A I M E R * * * * * * * * * * * * *
Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver weer en binden het INBO onder geen enkel beding, zolang dit bericht niet bevestigd is door een geldig ondertekend document.
The views expressed in this message and any annex are purely those of the writer and may not be regarded as stating an official position of INBO, as long as the message is not confirmed by a duly signed document.