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