Re: Observations on the 4.6rc1 windows package

[Tatsuro M. <tma...@ya...>]

--- On Sat, 2012/2/25, Juhász Péter wrote:

> On Sat, 2012-02-25 at 09:04 +0100, Bastian Märkisch wrote:
> > Am 17.02.2012 19:16, schrieb Juhász Péter:
> > > On Fri, 2012-02-17 at 18:56 +0100, Bastian Märkisch wrote:
> > >>
> > >> Am 17.02.2012 18:46, schrieb Ethan A Merritt:
> > >>> On Friday, February 17, 2012 09:35:20 am Juhász Péter wrote:
> > >>>>
> > >>>> - On one of my machines, startup appeared to be extremely slow, taking
> > >>>> about 5 minutes (!). This is true for both the console and GUI versions.
> > >>>> For the first few tries I've actually killed the process, because I
> > >>>> didn't have the patience to wait it out. Once it started, it appeared to
> > >>>> work normally, there were no delays and plotting was instantaneous as
> > >>>> well. (Older versions had a long delay at the first plot because of
> > >>>> fontconfig or whatever.)
> > >>>> This happened in both interactive and non-interactive mode, however,
> > >>>> only on a virtual machine running Vista. On a real computer running
> > >>>> Windows 7, startup was instantaneous.
> > >>>
> > >>> I seem to recall this was discussed a couple of years ago.
> > >>> The issue then was that if the program did not find a certain set of fonts,
> > >>> it triggered creation of a bitmap font set from the underlying font
> > >>> descriptions.  This was painfully slow but only  happened the first time,
> > >>> since subsequent runs would find the  now-created font set.
> > >>> However, I wonder if you run under a virtual machine whether every time
> > >>> is a "first" time?  Anyhow, my best guess is that this is a font issue
> > >>> rather than anything to do with gnuplot per se.
> > >>>
> > >>>     Ethan
> > >>>
> > >>
> > >> The cairo terminals no longer use the fontconfig mechanism of Windows,
> > >> so this particular issue should have been solved.
> > >> On the other hand I vaguely remember a similar report a while ago, but I
> > >> couldn't reproduce on various XP, Vista and 7 machines.
> > >>
> > >
> > > On further testing I've noticed that there *is* a slight delay on
> > > startup even on the Win7 machine (4-5 seconds). This means that even
> > > something like 'gnuplot -e "print 1"' takes this much time.
> > >
> > > Péter Juhász
> > >
> > 
> > Finally, I have been able to reproduce this delay on a Vista machine 
> > using Tatsuro Matsuoka's 4.5 and 4.6rc1 builds. Note that the "small" 
> > 4.5 build which does not include cairo and wxt terminals does not show 
> > the delay on start-up.
> > Also, I do not see any notable delay using my own build (including wxt 
> > and cairo), see
> > http://gnuplot.info/development/binaries/
> > Is anybody able to reproduce this observation?
> > 
> >    Bastian
> 
> 
> I've fired up that virtual machine that produced that 5 minute delay
> earlier. Some observations on several different builds:
> 
> gp46rc1-win32-setup.exe from http://gnuplot.info/development/binaries/
> (25-Feb-2012 07:19): a small (1-2 s) delay on startup.
> 
> gp450win32-small-setup.zip from
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/ (2012-02-23, md5sum
> feebe279501075f8806a04a4029f899c): No delay at all!
> 
> gp450win32-setup.zip from the same location (2012-02-23, md5sum
> 728918c93811f1644711c05fecaebd8f): several minutes of delay.
> 
> I thought that if the delay is related to the initialization of the wxt
> terminal, then setting the GNUTERM variable to "windows" may alleviate
> the problem, but it didn't.
> 
> Péter Juhász
> 
One of the possibility is that the version of wxwidgets.  Now I am using wxwidgets-2.9.3.
To be clear I have to rebuiild wxwidigts 2.8 and re-provide the binary.
Now my condition is not so good, I cannot commit further at the moment.

Sorry for inconvenience.

Tatsuro