We have a case where we are using the Linux tool called LATEX to create PDF files locally.
This is something that has been used for years and they haven't had any details.
Currently the cliente is using a new server and what happens is that to process a group of files to convert to PDF, from the Linux prompt it takes a few seconds, while with XCALL HOSTEX it takes much longer.
Is there a reason for this change in execution speed?
Hmmm.... that seems mysterious. Are you capturing the output (by passing the stdout parameter to HOSTEX)? If so, you might want to try removing it and just letting the output come to the screen, as the capture method is much more complex and may be somehow slowing it down. Otherwise, XCALL HOSTEX uses the standard Linux system() call, which is essentially what the bash shell uses to execute commands, so it's hard to see why it would run any slower.
I attach to your email a file with three videos due to the 5MB limit (I think this number is pretty low for current standards!)
The one called "sga host command" shows the conversion to PDF from the A-Shell prompt using "host pdflatex [filename]".
The one called "sga system command" is the one used by xcall hostex.
You can easily see that although it is a single file, the process takes a long time.
The video called "linux terminal" is the execution from the Linux prompt of the same command: pdflatex [file name] and you can see that it executes much more quickly.
This same video includes the execution for many files and the process takes less time than executing just one by the other mechanisms.
Probably there is something obvious that I'm not seeing at the moment!
If anyone else is interested in the videos I can send them to your email. Please let me know.
The one thing that makes sense is that the HOST version performs the same as your XCALL SYSTEM (which I'm assuming is an alias to XCALL HOSTEX), since that's exactly what HOST uses.
The one big difference between how bash executes the command, and how A-Shell HOSTEX does, is that bash uses the system commands fork() and exec(), whereas A-Shell uses the command system(), which acts as a convenience wrapper for fork() and exec(). It does add overhead (mainly for the setup, not for the execution) but there are apparently some subtle differences in the way the environment is shared that might have an effect on a command as complex as pdflatex. Normally that difference is virtually un-measurable.
As an example, I tried md5sum on a 1.5GB file (multiple times to eliminate cache differences) and the execution time was identical whether executed from bash or from A-Shell using HOST.
Since pdflatex is so complicated, with lots of sub-processes and intermediate files, maybe there is some operation that gets repeated in the midst of all that which is less efficient due to the slight difference in environment.
The one way to get A-Shell to use the fork() / exec() technique is with XCALL SUBMIT, which you could use instead of HOSTEX to see if it was faster. Your command would look something like:
Note that if the SBR=SUBMIT2 option is set in the miame.ini, this command should return immediately, so you would have to wait for the output to appear in the pdflatex.out file to measure how long it actually took to run. (Or maybe it doesn't matter, if the only goal is to get response back to your app as fast as possible.)
Using SUBMIT makes the speed execution is much better, but something strange is happening:
We're using a loop to submit several files to pdflatex but the EOF of this file is never being detected.
If we comment out the submit statement, then the EOF is detected properly.
I'm sending to your email a couple of videos to show how 34 files are being sent to pdflatex through SUBMIT. We had to put a hard-coded counter to 50 to stop de loop, otherwise it enters in a never ending cycle. Commenting the SUBMIT stops when the EOF is detected.
If someone else is interested in the subject I can share the videos. Please let me know.
From what I can see, you've got an input file with 34 lines, each containing information to be turned into a pdflatex command executed through SUBMIT. The loop looks something like this...
Code
CICLO:
INPUT LINE #888, LINEA
IF EOF(888) THEN GOTO FIN'CICLO
<... convert LINEA into NOMSAL$, NOMPDF$, ARCOUT$, ARCLOG$, NEWDIR$ ... >
XCALL SUBMIT, PID, NEWDIR$, ARCOUT$, ARCLOG$, "/usr/bin/pdflatex", NEWDIR$
GOTO CICLO
FIN'CICLO:
The IF EOF(888) never gets triggered. But if you comment out the XCALL SUBMIT, it works fine. Since the #888 file is not referenced by the SUBMIT command, it's hard to see what the connection is. To get more information, I would suggest adding another couple of lines after the IF EOF(888) ...
Code
trace.print (99,"submit") LINEA, EOF
IF LINEA = "" GOTO FIN'CICLO
I'm not sure what you're going to see, but perhaps it will be a clue. One possibility is that you see the last line repeated over and over again. Or maybe the line is blank but the eof doesn't get triggered. Or ....?
Another debug which might help pin this down would be to use SET TRACE FOPENS ON and SET TRACE RW ON and SET TRACE XCALL ON prior to running your test, so we obtain a log of the open and input operations, and can see the actual XCALL SUBMIT parameters, in case something unexpected shows up.
That's truly mysterious! I don't see anything weird in the trace, and can't think of any connection between the SUBMIT operation (which isn't even invoking A-Shell) and the current input file pointer.
I may have to investigate it more thoroughly here. Can you please clarify the environment (A-Shell and OS version)?
As a workaround, here's a suggestion (shouldn't be necessary, but easy to implement): Make a call to MX_FLINES to count the lines in the file before you enter the loop, and then change the loop control to use FOR COUNT = 1 TO TOTLINES...
For what it's worth, I created a test program for this (using /usr/bin/md5sum rather than pdflatex). And I've been unable to reproduce the problem, at least with 7.0.1764.1-el9. I suggest you download it and try it on the target system to see whether the issue is specific to pdflatex (hard to believe!) or else is related to some other detail of the way you are XCALLing SUBMIT. You could easily modify the program to use your input file and execute pdflatex to see whether the problem relates to some other difference between our two programs.
Rename SUBEOFTST.TXT to .BAS, VUE it, save it, compile it and then RUN it (in any directory). It uses the files SUB*.* as inputs to md5sum executed through XCALL SUBMIT, generating a .OUT file for each one. (You'll have at least 3 to start with -- the RUN, BAS and BAK -- and if you want a more extensive test, just create some additional SUB*.* files by COPYing from other any files of any type.) It also allows you to switch the SBR=SUBMIT2 option on and off to see whether that affects the behavior.
I had something similar happen and in my case something was stepping on the fcn (888 in this case) status. Just for fun have you changed the channel # you are using?
That seems like the logical explanation. I just can't see how commenting out the XCALL SUBMIT would affect it, given that it is executing an external command, in another process, unrelated to A-Shell. Surely the external command cannot be stepping on an A-Shell file channel. Possibly the XCALL SUBMIT itself could be the culprit, but in that case, it should have shown up in my test program. I thought it might be that the input file (lisemp.dat) was somehow being referenced by one of the XCALL SUBMIT parameters, but I don't see any evidence of that in the ashlog FOPENS traces.
