on their part native jobs IBMi have then much faster context switches during use, no TLB / cache trashing, that counts a lot in a system that values to be transactional and concurrent.
For example, for high throughput need in particular tasks, one would usually prestart X jobs that then read from a fast DTAQ and leave them on. This is a decent (and very fast...) design and the overall throughput can be also reasonably capped and manipulated and thought of, and also easily debugged.
Back to POSIX stuff, and the POSIX view of the world, yes, we often basically reduced the problem and the machines in a giant continuous string parsing and generating concoction, a practical, useful, at times fun, dance between processes. But that time spent compounds easily for non trivial problems in the data space, especially in systems where creation and tear up of processes is continuous.
....In any case, in PASE is worth using PHP or python (etc.) for things that surpasses the 10 lines of code, you get proper syntax and library support.... shell lang was built for shell problems...
------------------------------
--ft
------------------------------
Original Message:
Sent: Thu December 04, 2025 04:33 AM
From: Kurt Thomas
Subject: PASE performance question
This is the real reason, thanks, ace, for posting it. On Linux/Unix a fork "costs" next to nothing in performance terms, in PASE, it involves a much bigger machinery. Frank Soltis mentions this somewhere, in "Fortress", I think.
IBM i even had to prevent the fork jobs issuing QHST messages to keep the performance manageable.
------------------------------
Kurt Thomas
Senior System Engineere
Fortra
Original Message:
Sent: Thu June 09, 2022 04:17 AM
From: ac
Subject: PASE performance question
We are of course obliged to take in account that process creation in an "i" system is a much more heavy operation than a pure POSIX (simply because a process/job in i provides more capability/visibility/instrumentation etc.) and maybe - yes - it is also a codepath that still need some optimization - but - will never be the same as a pure unix (lighter weight) even with job prestarting...
in any case... which binaries are you using? GNUs?
post your "which sed grep awk bash" ....
------------------------------
ace ace
Original Message:
Sent: Tue June 07, 2022 08:01 AM
From: Glenn Robinson
Subject: PASE performance question
I have bash script which manipulates some text file using many grep, awk and sed statements.
When I run this on my V7R3 LPAR it takes around 6 minutes to run the script.
When I run the same script on my RHEL ppc64le LPAR it takes just 5.8 seconds.
Both LPARs are connected to the same FS7200 storage.
Both LPARs have have the same CPU and Memory assigned.
I'm guessing that when I use pipes or execute commands as in put to loops this is kicking off additional IBM i jobs which is why this takes so long comapred to RHEL.
Any suggestions/comments on how I can make PASE more performant so that I can get closer to RHEL performance?
Thanks
Glenn
------------------------------
Glenn Robinson
------------------------------