- ntg-pdftex - NTG Mailing Lists

[ pdftex-Support Requests-869 ] pdflatex slow to start on Cygwin
by noreply＠sarovar.org 23 Sep '07

23 Sep '07

Support Requests item #869, was opened at 2007-09-23 02:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Theo Hopman (thopman) Assigned to: Nobody (None) Summary: pdflatex slow to start on Cygwin Initial Comment: I use Cygwin on WinXP pro, with teTex 3.0 installed. I recently built pdftex 1.40 (which went well), manually replaced the old binaries of pdftex, and rebuilt the various formats using fmtutil. Now, however, pdflatex starts up only after a considerable delay (anywhere from a couple of seconds up to half a minute). While pdflatex sits there looking like its doing nothing, it also responds slowly to interrupt (^C) signals. Why might this be? `pdflatex --version`, by contrast, is instantaneous, so the issue is likely something to do with searching or loading formats. THeo ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-09-23 20:19 Message: Logged In: YES user_id=421 Please continue the discussion on the pdftex mailing list. ---------------------------------------------------------------------- Comment By: George N. White III (gnwiii) Date: 2007-09-23 20:16 Message: Logged In: YES user_id=4692 So path searching is not slow and CPU usage is slow, which indicates waiting for I/O. This could be loading files (.pool file, format, ...), console output, or file output. You didn't mention of whether files are on local disk or network, USB, etc. 1. on general principles, I'd do a disk cleanup and run chkdsk /f to make sure disks are OK. 2. check for signs of trouble in the event viewer. 3. run "pdftex -recorder story" and and "pdflatex -recorder sample2e" to check for files in unexpected locations, especially network or USB drives. 4. try a different terminal program -- there have been reports of widely varying performance between different terminals, remote ssh, etc. ---------------------------------------------------------------------- Comment By: Theo Hopman (thopman) Date: 2007-09-23 18:34 Message: Logged In: YES user_id=4690 kpsewhich shows no noticeable delay. pdftex 1.40 was slow when building formats. While pdftex is starting (and delaying), the system idle process is using 90%+ of CPU. The memory usage of pdftex does grow slowly, then jumps once it stops delaying. I don't think the problem is with search paths, because I didn't change these when I upgraded, and besides, kpathsea seems to be plenty fast still. THeo ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-23 13:56 Message: Logged In: NO Is kpathsea also slow? Was pdftex 1.40 slow when building formats? What do you see in the Windows process viewer (there are two CPU columns, one shows cumulative CPU time and the other current CPU usage, by default only one is shown)? For me, when apps are slow to start it is usually mcafee that is using 98% of CPU. Matlab takes over 2 minutes to start with McAfee running, but only a few seconds with McAfee configured to ignore the Matlab directory. Are there network directories in the search path? I use Win32 at work were the users "HOME" directory is on a network drive, but many users systems don't correctly negotiate the duplex setting with the ethernet switch. When network access is slow, running the network "repair" tool (sometimes takes several attempts) will (usually, eventually) make things better (linux has mii-tool where I can check the duplex setting and force it to full). If "man pdftex" is working, look for: -recorder Enable the filename recorder. This leaves a trace of the files opened for input and output in a file with extension .fls. This still omits a few files, but may give you a hint. Have you tried simplifying the search paths in texmf.cnf? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106

1 0

[ pdftex-Support Requests-869 ] pdflatex slow to start on Cygwin
by noreply＠sarovar.org 23 Sep '07

23 Sep '07

Support Requests item #869, was opened at 2007-09-22 21:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Theo Hopman (thopman) Assigned to: Nobody (None) Summary: pdflatex slow to start on Cygwin Initial Comment: I use Cygwin on WinXP pro, with teTex 3.0 installed. I recently built pdftex 1.40 (which went well), manually replaced the old binaries of pdftex, and rebuilt the various formats using fmtutil. Now, however, pdflatex starts up only after a considerable delay (anywhere from a couple of seconds up to half a minute). While pdflatex sits there looking like its doing nothing, it also responds slowly to interrupt (^C) signals. Why might this be? `pdflatex --version`, by contrast, is instantaneous, so the issue is likely something to do with searching or loading formats. THeo ---------------------------------------------------------------------- Comment By: George N. White III (gnwiii) Date: 2007-09-23 15:16 Message: Logged In: YES user_id=4692 So path searching is not slow and CPU usage is slow, which indicates waiting for I/O. This could be loading files (.pool file, format, ...), console output, or file output. You didn't mention of whether files are on local disk or network, USB, etc. 1. on general principles, I'd do a disk cleanup and run chkdsk /f to make sure disks are OK. 2. check for signs of trouble in the event viewer. 3. run "pdftex -recorder story" and and "pdflatex -recorder sample2e" to check for files in unexpected locations, especially network or USB drives. 4. try a different terminal program -- there have been reports of widely varying performance between different terminals, remote ssh, etc. ---------------------------------------------------------------------- Comment By: Theo Hopman (thopman) Date: 2007-09-23 13:34 Message: Logged In: YES user_id=4690 kpsewhich shows no noticeable delay. pdftex 1.40 was slow when building formats. While pdftex is starting (and delaying), the system idle process is using 90%+ of CPU. The memory usage of pdftex does grow slowly, then jumps once it stops delaying. I don't think the problem is with search paths, because I didn't change these when I upgraded, and besides, kpathsea seems to be plenty fast still. THeo ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-23 08:56 Message: Logged In: NO Is kpathsea also slow? Was pdftex 1.40 slow when building formats? What do you see in the Windows process viewer (there are two CPU columns, one shows cumulative CPU time and the other current CPU usage, by default only one is shown)? For me, when apps are slow to start it is usually mcafee that is using 98% of CPU. Matlab takes over 2 minutes to start with McAfee running, but only a few seconds with McAfee configured to ignore the Matlab directory. Are there network directories in the search path? I use Win32 at work were the users "HOME" directory is on a network drive, but many users systems don't correctly negotiate the duplex setting with the ethernet switch. When network access is slow, running the network "repair" tool (sometimes takes several attempts) will (usually, eventually) make things better (linux has mii-tool where I can check the duplex setting and force it to full). If "man pdftex" is working, look for: -recorder Enable the filename recorder. This leaves a trace of the files opened for input and output in a file with extension .fls. This still omits a few files, but may give you a hint. Have you tried simplifying the search paths in texmf.cnf? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106

1 0

[ pdftex-Support Requests-869 ] pdflatex slow to start on Cygwin
by noreply＠sarovar.org 23 Sep '07

23 Sep '07

Support Requests item #869, was opened at 2007-09-22 20:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Theo Hopman (thopman) Assigned to: Nobody (None) Summary: pdflatex slow to start on Cygwin Initial Comment: I use Cygwin on WinXP pro, with teTex 3.0 installed. I recently built pdftex 1.40 (which went well), manually replaced the old binaries of pdftex, and rebuilt the various formats using fmtutil. Now, however, pdflatex starts up only after a considerable delay (anywhere from a couple of seconds up to half a minute). While pdflatex sits there looking like its doing nothing, it also responds slowly to interrupt (^C) signals. Why might this be? `pdflatex --version`, by contrast, is instantaneous, so the issue is likely something to do with searching or loading formats. THeo ---------------------------------------------------------------------- >Comment By: Theo Hopman (thopman) Date: 2007-09-23 12:34 Message: Logged In: YES user_id=4690 kpsewhich shows no noticeable delay. pdftex 1.40 was slow when building formats. While pdftex is starting (and delaying), the system idle process is using 90%+ of CPU. The memory usage of pdftex does grow slowly, then jumps once it stops delaying. I don't think the problem is with search paths, because I didn't change these when I upgraded, and besides, kpathsea seems to be plenty fast still. THeo ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-23 07:56 Message: Logged In: NO Is kpathsea also slow? Was pdftex 1.40 slow when building formats? What do you see in the Windows process viewer (there are two CPU columns, one shows cumulative CPU time and the other current CPU usage, by default only one is shown)? For me, when apps are slow to start it is usually mcafee that is using 98% of CPU. Matlab takes over 2 minutes to start with McAfee running, but only a few seconds with McAfee configured to ignore the Matlab directory. Are there network directories in the search path? I use Win32 at work were the users "HOME" directory is on a network drive, but many users systems don't correctly negotiate the duplex setting with the ethernet switch. When network access is slow, running the network "repair" tool (sometimes takes several attempts) will (usually, eventually) make things better (linux has mii-tool where I can check the duplex setting and force it to full). If "man pdftex" is working, look for: -recorder Enable the filename recorder. This leaves a trace of the files opened for input and output in a file with extension .fls. This still omits a few files, but may give you a hint. Have you tried simplifying the search paths in texmf.cnf? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106

1 0

[ pdftex-Support Requests-869 ] pdflatex slow to start on Cygwin
by noreply＠sarovar.org 23 Sep '07

23 Sep '07

Support Requests item #869, was opened at 2007-09-23 06:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Theo Hopman (thopman) Assigned to: Nobody (None) Summary: pdflatex slow to start on Cygwin Initial Comment: I use Cygwin on WinXP pro, with teTex 3.0 installed. I recently built pdftex 1.40 (which went well), manually replaced the old binaries of pdftex, and rebuilt the various formats using fmtutil. Now, however, pdflatex starts up only after a considerable delay (anywhere from a couple of seconds up to half a minute). While pdflatex sits there looking like its doing nothing, it also responds slowly to interrupt (^C) signals. Why might this be? `pdflatex --version`, by contrast, is instantaneous, so the issue is likely something to do with searching or loading formats. THeo ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-23 17:26 Message: Logged In: NO Is kpathsea also slow? Was pdftex 1.40 slow when building formats? What do you see in the Windows process viewer (there are two CPU columns, one shows cumulative CPU time and the other current CPU usage, by default only one is shown)? For me, when apps are slow to start it is usually mcafee that is using 98% of CPU. Matlab takes over 2 minutes to start with McAfee running, but only a few seconds with McAfee configured to ignore the Matlab directory. Are there network directories in the search path? I use Win32 at work were the users "HOME" directory is on a network drive, but many users systems don't correctly negotiate the duplex setting with the ethernet switch. When network access is slow, running the network "repair" tool (sometimes takes several attempts) will (usually, eventually) make things better (linux has mii-tool where I can check the duplex setting and force it to full). If "man pdftex" is working, look for: -recorder Enable the filename recorder. This leaves a trace of the files opened for input and output in a file with extension .fls. This still omits a few files, but may give you a hint. Have you tried simplifying the search paths in texmf.cnf? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106

1 0

[ pdftex-Support Requests-869 ] pdflatex slow to start on Cygwin
by noreply＠sarovar.org 23 Sep '07

23 Sep '07

Support Requests item #869, was opened at 2007-09-22 20:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Theo Hopman (thopman) Assigned to: Nobody (None) Summary: pdflatex slow to start on Cygwin Initial Comment: I use Cygwin on WinXP pro, with teTex 3.0 installed. I recently built pdftex 1.40 (which went well), manually replaced the old binaries of pdftex, and rebuilt the various formats using fmtutil. Now, however, pdflatex starts up only after a considerable delay (anywhere from a couple of seconds up to half a minute). While pdflatex sits there looking like its doing nothing, it also responds slowly to interrupt (^C) signals. Why might this be? `pdflatex --version`, by contrast, is instantaneous, so the issue is likely something to do with searching or loading formats. THeo ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106

1 0

[Fwd: Re: \suppressfontnotfounderror (Re: \nofontnotfounderror patch)]
by Taco Hoekwater 18 Sep '07

18 Sep '07

FYI (Jonathan is on the discards list) Cheers, Taco -------- Original Message -------- Subject: Re: \suppressfontnotfounderror (Re: [NTG-pdftex] \nofontnotfounderror patch) Date: Mon, 17 Sep 2007 17:27:31 +0100 From: Jonathan Kew <jonathan_kew(a)sil.org> To: Taco Hoekwater <taco(a)elvenkind.com> CC: pdfTeX developers list <ntg-pdftex(a)ntg.nl>, Will Robertson <wspr81(a)gmail.com> References: <46EE77A5.2030205(a)elvenkind.com> <46EE9ED9.7080000(a)elvenkind.com> OK, this is now included in the xetex svn sources as well, with the name \suppressfontnotfounderror. Thanks, JK On 17 Sep 2007, at 4:35 pm, Taco Hoekwater wrote: > > Hi, > > Phil Taylor and I just had an email exchange about the name of > the primitive, and after a few messages he convinced me that it > is better not to have a double negation in the name because > it is not unlikely that will not prevent people from becoming > confused. So, here is an updated patch with the new name: > > \suppressfontnotfounderror > > Best wishes, > Taco

1 0

[ pdftex-Patches-864 ] \suppressfontnotfounderror patch
by noreply＠sarovar.org 18 Sep '07

18 Sep '07

Patches item #864, was opened at 2007-09-17 17:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106 Category: Primitives Group: v1.50.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \suppressfontnotfounderror patch Initial Comment: Attached is a patch for pdftex 1.50 (current trunk) that introduces a new integer parameter named \suppressfontnotfounderror. If this parameter is non-zero, then (pdf)tex will not complain about font metric files that are not found, but silently skip the font assignment, making the requested csname \ifx-equal to \nullfont. The purpose is to allow macro programmers a way to gracefully recover from a missing or differently named font. I am aware there is a trick that uses \batchmode to test for font existance, but the downside of that is that it calls TeX's error() routine, which clobbers the executable's return value. That makes it a no-no in "make"-like environments where the return value of TeX is checked to decide on further actions. This functionality will also be added to the next versions of xetex and luatex (that's why the name does not start with \pdf...). % simple example usage \def\testfont#1{% \font\junk=#1 \ifx\junk\nullfont \message{Font #1 not found} \else \message{Font #1 found} \fi } {\suppressfontnotfounderror=1 \testfont{cmr-junk} } \bye ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-09-18 08:10 Message: Logged In: YES user_id=1608 Well, at least it does not affect the tex user directly: there is a stream of garbage on the screen and that looks ugly, but there is no error interaction, and the system-level return value of pdftex is unaffected. I don't know if there is a clean way to control mktextfm cs, but if it can be done, that would be a nice addition to the web2c change file. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-09-17 21:53 Message: Logged In: YES user_id=421 IMHO it works only somuch, but that may be due to kpathsea: > pdftex test.tex This is pdfTeX, Version 3.141592-1.50.0-alpha-20070917 (Web2C 7.5.6) entering extended mode (./test.texkpathsea: Running mktextfm cmr-junk mktextfm: Running mf-nowin -progname=mf \mode:=lexmarkr; mag:=1; nonstopmode; input cmr-junk This is METAFONT, Version 2.71828 (Web2C 7.5.4) kpathsea: Running mktexmf cmr-junk ! I can't find file `cmr-junk'. <*> ...xmarkr; mag:=1; nonstopmode; input cmr-junk Please type another input file name ! Emergency stop. <*> ...xmarkr; mag:=1; nonstopmode; input cmr-junk Transcript written on mfput.log. grep: cmr-junk.log: Datei oder Verzeichnis nicht gefunden mktextfm: `mf-nowin -progname=mf \mode:=lexmarkr; mag:=1; nonstopmode; input cmr-junk' failed to make cmr-junk.tfm. kpathsea: Appending font creation commands to missfont.log. Font cmr-junk not found ) No pages of output. Transcript written on test.log. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106

1 0

[ pdftex-Patches-864 ] \suppressfontnotfounderror patch
by noreply＠sarovar.org 17 Sep '07

17 Sep '07

Patches item #864, was opened at 2007-09-17 17:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106 Category: Primitives Group: v1.50.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Taco Hoekwater (taco) >Assigned to: Martin Schröder (oneiros) Summary: \suppressfontnotfounderror patch Initial Comment: Attached is a patch for pdftex 1.50 (current trunk) that introduces a new integer parameter named \suppressfontnotfounderror. If this parameter is non-zero, then (pdf)tex will not complain about font metric files that are not found, but silently skip the font assignment, making the requested csname \ifx-equal to \nullfont. The purpose is to allow macro programmers a way to gracefully recover from a missing or differently named font. I am aware there is a trick that uses \batchmode to test for font existance, but the downside of that is that it calls TeX's error() routine, which clobbers the executable's return value. That makes it a no-no in "make"-like environments where the return value of TeX is checked to decide on further actions. This functionality will also be added to the next versions of xetex and luatex (that's why the name does not start with \pdf...). % simple example usage \def\testfont#1{% \font\junk=#1 \ifx\junk\nullfont \message{Font #1 not found} \else \message{Font #1 found} \fi } {\suppressfontnotfounderror=1 \testfont{cmr-junk} } \bye ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-09-17 21:53 Message: Logged In: YES user_id=421 IMHO it works only somuch, but that may be due to kpathsea: > pdftex test.tex This is pdfTeX, Version 3.141592-1.50.0-alpha-20070917 (Web2C 7.5.6) entering extended mode (./test.texkpathsea: Running mktextfm cmr-junk mktextfm: Running mf-nowin -progname=mf \mode:=lexmarkr; mag:=1; nonstopmode; input cmr-junk This is METAFONT, Version 2.71828 (Web2C 7.5.4) kpathsea: Running mktexmf cmr-junk ! I can't find file `cmr-junk'. <*> ...xmarkr; mag:=1; nonstopmode; input cmr-junk Please type another input file name ! Emergency stop. <*> ...xmarkr; mag:=1; nonstopmode; input cmr-junk Transcript written on mfput.log. grep: cmr-junk.log: Datei oder Verzeichnis nicht gefunden mktextfm: `mf-nowin -progname=mf \mode:=lexmarkr; mag:=1; nonstopmode; input cmr-junk' failed to make cmr-junk.tfm. kpathsea: Appending font creation commands to missfont.log. Font cmr-junk not found ) No pages of output. Transcript written on test.log. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106

1 0

[ pdftex-Patches-864 ] \suppressfontnotfounderror patch
by noreply＠sarovar.org 17 Sep '07

17 Sep '07

Patches item #864, was opened at 2007-09-17 17:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106 >Category: Primitives >Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) Summary: \suppressfontnotfounderror patch Initial Comment: Attached is a patch for pdftex 1.50 (current trunk) that introduces a new integer parameter named \suppressfontnotfounderror. If this parameter is non-zero, then (pdf)tex will not complain about font metric files that are not found, but silently skip the font assignment, making the requested csname \ifx-equal to \nullfont. The purpose is to allow macro programmers a way to gracefully recover from a missing or differently named font. I am aware there is a trick that uses \batchmode to test for font existance, but the downside of that is that it calls TeX's error() routine, which clobbers the executable's return value. That makes it a no-no in "make"-like environments where the return value of TeX is checked to decide on further actions. This functionality will also be added to the next versions of xetex and luatex (that's why the name does not start with \pdf...). % simple example usage \def\testfont#1{% \font\junk=#1 \ifx\junk\nullfont \message{Font #1 not found} \else \message{Font #1 found} \fi } {\suppressfontnotfounderror=1 \testfont{cmr-junk} } \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106

1 0

[ pdftex-Patches-864 ] \suppressfontnotfounderror patch
by noreply＠sarovar.org 17 Sep '07

17 Sep '07

Patches item #864, was opened at 2007-09-17 17:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) Summary: \suppressfontnotfounderror patch Initial Comment: Attached is a patch for pdftex 1.50 (current trunk) that introduces a new integer parameter named \suppressfontnotfounderror. If this parameter is non-zero, then (pdf)tex will not complain about font metric files that are not found, but silently skip the font assignment, making the requested csname \ifx-equal to \nullfont. The purpose is to allow macro programmers a way to gracefully recover from a missing or differently named font. I am aware there is a trick that uses \batchmode to test for font existance, but the downside of that is that it calls TeX's error() routine, which clobbers the executable's return value. That makes it a no-no in "make"-like environments where the return value of TeX is checked to decide on further actions. This functionality will also be added to the next versions of xetex and luatex (that's why the name does not start with \pdf...). % simple example usage \def\testfont#1{% \font\junk=#1 \ifx\junk\nullfont \message{Font #1 not found} \else \message{Font #1 found} \fi } {\suppressfontnotfounderror=1 \testfont{cmr-junk} } \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106

1 0