Description of problem: gs7.05 has a bug that causes repetitive calls to it to be *very* slow; I submitted a sample postscript file and shell script that demonstrates the slowness; my fix was to compile 7.07 from source and distribute to all of my boxes but I would like the RHEL distro to upgrade to 7.07 asap so I can better manage the servers Using gs7.05: [root@dragon root]# time ./my.bash real 7m6.538s user 0m11.690s sys 0m1.550s [root@dragon root]# time ./my.bash real 0m7.024s user 0m5.830s sys 0m1.040s Version-Release number of selected component (if applicable): ghostscript 7.05 How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 102941 [details] sample postscript for testing Use this with my.bash for test data.
Created attachment 102942 [details] bash script to loop thru creation of pdf on the fly Use this script and the my.ps to see slowness on gs7.05. If you upgrade to gs7.07, it works. Let me know if you need more info.
We don't do version upgrades for Red Hat Enterprise Linux. This issue surely doesn't only affect repetitive invocations of ghostscript, but all invocations -- so in fact, isn't it just that 7.07 is faster?
No. I think there is some temp file issue or something. A handful of calls to the program and there is not a noticeable difference. When you call it *alot* is when it breaks down. (I'm not sure why. I was going to go thru the changelog to see if I could figure it out, but I gave up.) This is not a version upgrade. It is a minor patch upgrade. (Then again... what do I know?!?) You do these all of the time with all sorts of packages. (perhaps this 7.05->7.07 requires more than just this package? Perhaps glibc or something. I dunno...) This is the only time that I've been bitten by the way that RH manages the boxes. I cannot use up2date to keep ghostscript current as I've manually patched the boxen. I would like to undo that and stay "vanilla" if at all possible. I saw that you're going to put gs7.07 in FedoraCore2 so that's a positive sign, no?
Please replace 'gs ...' with 'time gs ...' in your script and show some sample output.
I bet this is the same problem as bug 97583. gs 7.05 is using /dev/random rather than /dev/urandom and so gets very slow after multiple invocations have used up the available entropy.
Yes, you're probably right. *** This bug has been marked as a duplicate of 97583 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.