ast: serious performance breakdown of ksh2020 in comparison to ksh93u+
Description of problem:
consider a stupid micro benchmark like ` function repeatloop { nameref count=$1 integer i=0 buf=0 for ((i=0; i< $count; i++)); do ((buf++)) : done print $buf }
count=1000000 time repeatloop count `
Ksh version: on my machine (OSX 10.4.6, powerbook)
93u+: 1.01s 2020 release: 2.12s head (42a580c5): 2.98s
How reproducible: always
Steps to reproduce: run above script
Actual results:
100-200% slow down (i.e. by a factor 2-3!) of ksh2020 in comparison to 93u+. although ksh2020 thus remains faster than bash (11s) the “order of magnitude faster than bash” is no more . if this is not fixed one might consider to copy this line from the bash manpage: “It’s too big and too slow.”
I find a performance breakdown by such a massive factor disconcerting. it is a big step back from ksh93u+.
Expected results:
competitive performance
Additional info:
do people see this behaviour on other platforms, too?
KornShell language is not only a command interpreter for interactive use. it also is a serious programming language. performance matters a lot. ksh always had by far the best performance of the major shells. current development in this ksh2020 project seems to severely damage ksh in this respect. I hope this can be fixed. are there performance benchmarks in the test suite at all?
About this issue
- Original URL
- State: open
- Created 5 years ago
- Comments: 29 (10 by maintainers)
Wow! That anyone thinks ksh is the appropriate tool for tasks such as computing the value of pi, other than in a “can this be done” way, blows my mind. I have to wonder how many languages that person has mastered.
@krader1961 :
need I explain to you the meaning of the word “benchmark”? do you object against the benchmark computing something where the correct result is known a priori and can be asserted? what is your problem except that ksh2020 is overall much slower than ksh93u+ (although"only" 13% in this special floating point benchmark)? it is quite obvious that you don’t want to admit that the slowdown is your fault (you haven’t). you would prefer to deny existence of the problem (you have). you also might consider to deny it’s relevance: actually, I am a bit disappointed that you have not yet done that (“ksh2020 is much slower than ksh93u+, but nobody wants a fast shell anyway since it is only a command interpreter like fish and ksh is not a serious scripting language etc etc etc pp”).
care to adjust your tone? care to just read through this very thread? https://github.com/att/ast/issues/1449#issuecomment-559092391. hint: search for the secret word “memory”.
also: care to explain to the world, why you managed to plow ahead for two years without ever caring to write your own small scripts for performance monitoring? and then making a “stable” release (build(ing) w/o the minsize flag) that was/is about a factor of 2-3 slower across the board than ksh93u+? care to give this engineering feat a grade from A to F?
so far you maintained (do you, still?) that the problem has “almost nothing to do with [code] changes made in the past two years”. that is obviously completely (and wittingly) untrue. all of the remaining issues (assuming minsize as a future default build option) we are now talking about are due to code changes. whether your changes to the memory management or your “code tidy up” and your “optimisations” takes most of the responsibility for the slow down or both are equally the culprit remains to be seen.
you do agree with what? just let the readers know.
I (and several other people) have received a clear message from you again and again: you don’t want real feedback. you don’t want being pointed to real problems. you don’t understand them. you deny them. you don’t like being caught in the act of telling falsehoods to the readers here and on the mailing list. you don’t correct your attitude. you don’t listen. your reactions reliably are rude and arrogant. you are fighting a fight against the code (and its creators) and against the users of ksh who are noting that something wrong is happening due to your interference and are trying to make you realise that you need to correct your approach. you are short-sighted and rather clueless in all things ksh. that will not change. I know that by now. really.
so please understand that my posts here are just documenting the problems of ksh2020 for the future. whether you acknowledge or deny them or ignore them is of secondary concern. I posted the benchmark tables and the code for people to copy+paste and see for themselves. somewhere down the road this might help to repair the damage you have done.