JOB command as much as five times faster
# Final Release Note
The [JOB](https://docs.yottadb.com/ProgrammersGuide/commands.html#job) command is as much as five times faster than it was previously. This slowdown was an unintended side effect of changes to [GTM-9058](http://tinco.pair.com/bhaskar/gtm/doc/articles/GTM_V6.3-007_Release_Notes.html#GTM-9058) in GT.M V6.3-007 which was merged into YottaDB [r1.26](https://gitlab.com/YottaDB/DB/YDB/-/releases#r126-1). As a practical matter, you may not notice this unless you are launching hundreds, or even thousands, of processes in rapid succession. [#1181]
# Description
This is something I noticed while trying to start thousands of processes for benchmarks as part of YDB#1178.
Starting 10000 processes took a lot longer from r1.26 onwards whereas with r1.24 it was noticeably faster.
Some more analysis showed the slowdown happened in GT.M V6.3-007.
Below is a simple test case demonstrating the slowdown.
```m
$ cat lotsofjobs.m
set njobs=+$zcmdline
set start=$zut
for i=1:1:njobs job child set child(i)=$zjob
set mid=$zut
write "Starting ",njobs," processes took ",(mid-start)/(10**6)," seconds",!
for i=1:1:njobs set pid=child(i) for quit:'$zgetjpi(pid,"ISPROCALIVE") hang 0.001
quit
child ;
quit
```
**V6.3-006 output**
```sh
$ $gtm_dist/mumps -run lotsofjobs 10000
Starting 10000 processes took 6.71812 seconds
```
**V6.3-007 output**
```sh
$ $gtm_dist/mumps -run lotsofjobs 10000
Starting 10000 processes took 31.942112 seconds
```
Notice how starting 10,000 processes took 6.71 seconds in V6.3-006 but took 31.94 seconds in V6.3-007.
Finally narrowed down the slowdown to the following change in GT.M V6.3-007.
[GTM-9058](http://tinco.pair.com/bhaskar/gtm/doc/articles/GTM_V6.3-007_Release_Notes.html#GTM-9058)
> GT.M handles JOB errors differently. Errors associated with the specified routine, label, or offset appear in the error file of the JOBbed process in detail in addition to the JOBFAIL error received by the original process. Previously GT.M did not report the more specific errors and did not start the JOBbed process. GT.M detects and reports JOBLVN2LONG errors in the original process; GT.M does not start the JOBbed process in this case. Previously the JOBbed process would report JOBLVN2LONG to its error file. (GTM-9058)
It would be desirable to implement the `GTM-9058` fix without the unintended loss of performance that came along with it. Hence this issue.
# Draft Release Note
JOB command returns significantly faster. Previously, it used to take almost 5 times longer to return. This slowdown was an unintended side effect of changes to `GTM-9058` in GT.M V6.3-007 which got merged into YottaDB r1.26.
issue