Re: performance bug of [[ $x ]]

2020-03-07 Thread Lawrence Velázquez
> On Mar 7, 2020, at 7:33 PM, Peng Yu wrote: > > Could you show me how you do the profiling for this specific case? > Based on what proof that you can conclude that it is not the `[[` > performance problem? That's kind of a weird framing. The burden of proof is on *you* to prove your assertion t

Re: performance bug of [[ $x ]]

2020-03-07 Thread Peng Yu
My OS is Mac OS X. I don't have perf. Is it only on linux? Could you show me the output of your perf? On 3/7/20, Chris Down wrote: > Peng Yu writes: >>Could you show me how you do the profiling for this specific case? >>Based on what proof that you can conclude that it is not the `[[` >>performan

Re: performance bug of [[ $x ]]

2020-03-07 Thread Chris Down
Peng Yu writes: Could you show me how you do the profiling for this specific case? Based on what proof that you can conclude that it is not the `[[` performance problem? Like I said, `perf` is perfectly adequate. bash -c 'x=$(printf "%.sx" {1..1000}); perf record -g -p $$ & sleep 2; t

Re: performance bug of [[ $x ]]

2020-03-07 Thread Peng Yu
Could you show me how you do the profiling for this specific case? Based on what proof that you can conclude that it is not the `[[` performance problem? On 3/7/20, Chris Down wrote: > Peng Yu writes: >>[[ $x ]] just tests whether the variable $x is of length 0 or not. So >>its performance should

Re: performance bug of [[ $x ]]

2020-03-07 Thread Chris Down
Peng Yu writes: [[ $x ]] just tests whether the variable $x is of length 0 or not. So its performance should not depend on how long the variable is. Who said it has anything to do with the [[ builtin's performance? A shell does a lot more than just running one command. For this and the last

performance bug of [[ $x ]]

2020-03-07 Thread Peng Yu
[[ $x ]] just tests whether the variable $x is of length 0 or not. So its performance should not depend on how long the variable is. But the following test case shows that the run time does depend on the length of the variable. Should it be considered as a performance bug of bash? $ x=$(printf '

Performance bug of {1..1000000}?

2020-03-07 Thread Peng Yu
See the following run time comparison. {1..100} is slower than $(seq 100). Since seq involves an external program, I'd expect the latter to be slower. But the comparison shows the opposite. I guess seq did some optimization? Can the performance of {1..100} be improved so that it is f