On Sun, 20 Apr 2003, Alex Semenyaka wrote: > 7 5.20 6.37 3.51 22.50% i=$(($i<<1)) > 8 5.25 6.42 3.51 22.27% i=$(($i<<$m)) > > As you can see, even for arithmetic-only script the overhead is not too big > except with one case: shift operation. I decided to investigate is it usual > script operation. I've went through all scripts I could find in my FreeBSD > box. I've searched them with "locate .sh | grep '\.sh$'". There were a lot > of them: > > $ locate .sh | grep '\.sh$' | wc -l > 1637 > > But there was no any script that uses the shift operation. Good, but not > enough. I've take the script that uses arithmetics and do some other job, > ttfadmin.sh from the Abiword package. I've run in 10000 times in the loop > with both (64-bit and 32-bit) shells. As an argument it received empty > directory so no work has been done, just run, check pars, found no files, > exit. It takes 65.35 seconds in the first case and 65.30 second in the second > one. So the the time that arithmetics takes during the real script execution > is too small in comparison to total running time (obviously: arithmetics > is in-core calculations while any script usually run some external programs > etc, and at least I/O is involved). Ahem - wouldn't it be easier to find out *why* the dramatic speed-down happens and trying to combat it as opposed to trying to show the speed-down is not releavant? There shouldn't be anything inherently that much slower in 64 bit shifts... > > Thanks! > > SY, Alex >Received on Mon Apr 21 2003 - 14:39:54 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:04 UTC