On Tue, 13 Jul 2010, Hélio Guilherme wrote: Just thinking out loud, really: I don't really know what gnuplot does on its maiden voyage, but whatever it is, couldn't we ask gnuplot to do a "dry run" as part of the gretl installation process? Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti

On Windows XP (AMD 3000+, 2.16Ghz, with 1.5g memory) (through SP2) I find this to be the case only after a reboot. Open GRETL (1.91cvs) Open a data set Click on a series Ask for a time-series graph 10s to display Close GRETL and repeat: <1s. ~Peter On 7/13/2010 5:40 PM, Allin Cottrell wrote:

On Tue, 13 Jul 2010, peter wrote: Thanks for the info. This narrows the issue down. One more question: how does the start-up time for gretl itself compare depending on whether it's the first invocation since booting Windows, versus closing gretl and restarting it? Is that difference less extreme than for a gnuplot graph? Oh, and another experiment people could try, if they have the patience: what about the start-up time for wgnuplot.exe (the executable is in the gretl installation directory), independent of gretl? I'm thinking that the time to place a gretl/gnuplot graph on the screen is not all "gnuplot time": gnuplot is called to generate a PNG file, which gretl then displays using GTK/GDK, and the load time for the relevant GTK modules may be a factor. Allin

On Wed, 14 Jul 2010, peter wrote: Thanks, Peter. My experience matches yours. I have occasionally seen quite slow time-to-plot but I find it's not reproducible. This evening I tried an experiment on MS Windows Vista, after putting into gretl some timing code to measure the various phases of the on-screen plotting operation, which are basically three: (i) prepare the source file to send to gnuplot; (ii) call gnuplot to generate a PNG file; and (iii) process the PNG file and get its contents into a GTK window. I thought that if the plot took a long time to appear I would see where the problem was. I took what I thought was the worst-case scenario: boot Windows, remove gretl, install the current snapshot, start gretl, and try a plot. I did, however, let Windows "settle" a little after booting (opened Firefox, waited several seconds until it became properly responsive, visited the gretl site and downloaded the Windows snapshot, closed Firefox.) Anyway, here are my timings (note that they're not cumulative, each figure represents seconds elapsed since the last way-station): # first plot (single time-series) calling gnuplot() execing wgnuplot.exe: 0.016 wgnuplot.exe done: 0.717 gnuplot() returned 0: 0 gnuplot_show_png starting: 0 done read_plotspec_from_file: 0 get_png_bounds_info(): OK calling render_pngfile: 0.016 done render_pngfile: 0.062 # second plot (single time-series) calling gnuplot() execing wgnuplot.exe: 0 wgnuplot.exe done: 0.343 gnuplot() returned 0: 0 gnuplot_show_png starting: 0 done read_plotspec_from_file: 0 get_png_bounds_info(): OK calling render_pngfile: 0.015 done render_pngfile: 0.016 The second plot was faster, but even the first one took only about 0.8 seconds. The machine is a Lenovo T400 (Intel Core2 Duo CPU P8600 @ 2.40GHz), fairly fast but nothing out of the ordinary. If anyone else wants to try this, use tonight's Windows snapshot and run gretlw32.exe with the --debug option. To get the full effect of the timing code, open a time-series dataset and select a single series for plotting. The timer output should appear in a console window. What I conclude from this is that there's no inherent problem in the gretl/gnuplot/GTK code. If people are seeing very slow plot times it seems that's an operating system issue. Allin Cottrell

Dear all I tried many testing of the above script and results are as follows. Note that case (a) takes about 27 seconds. I have three win XP computers. Before I keep the following experimental records, I found the same issue as described earlier. This is the last one I encounter the delayed gnuplot problem. A strange thing is that I am not able to replicate the delayed plot issue even I re-install gretl 1.8.6 and upgrade it to 1.9.1cvs, or after rebooting winxp and do the upgrading again. Thanks Yi-Nung <script> open djclose smpl 1988/01/04 1989/12/29 set echo off set messages off set stopwatch printf "Beginning time ====>%.4f\n", $stopwatch gf1 <- gnuplot djclose --time-series --output=display --with-lines gf1.show set messages on printf "Ending time ====> %.4f\n", $stopwatch </script> (a). Run after a fresh installation of gretl 1.9.1 cvs for windows (upgrading from previous 1.8.6) Beginning time ====>0.0000 gf1 saved Ending time ====> 27.1690 (b). Run the script again immediately after (a) Beginning time ====>0.0000 gf1 saved Ending time ====> 0.5210 (c) Reboot the computer and run the script again Beginning time ====>0.0000 gf1 saved Ending time ====> 0.6310 (d) run the script again after (c) Beginning time ====>0.0000 gf1 saved Ending time ====> 0.5300 (e) after step (d), re-install a previous version (gretl-1.8.6) and run the script Beginning time ====>0.0000 gf1 saved Ending time ====> 0.5510