sent 21:30:38 27 November 2010, Saturday
by hsitz:
> Zyx -- That's an interesting approach. My main plan has been to go
> through and refactor at some point (probably coming soon now) to make
> sure all the globals have a prefix of 'org_' or something else that
> would diffferentiate them from other plugins.
>
> The dictionary approach sounds interesting but I wonder about the
> performance implications. I know Dicts are indexed, but won't there
> still be noticeable slowdown if that approach is used in loop
> repeated, say, 1,000 times? 10,000 times? Or is dict approach better
> limited to cases where variable is referenced in situation where
> performance isn't an issue?
Performance penalty is insignificant here: the following test on my machine
emits the following results:
1000000 (1e6) iterations
dict:
2.491708
4.262242
6.753950
dictdot:
2.194558
3.899753
6.094311
var:
2.179728
3.792891
5.972619
It is about 10% penalty when using [] syntax and only 2% when using dot syntax:
It looks like vim is using the same hash function for both for dictionary and
variable lookup. Here is a table created by
for (( I=250000 ; I<=2000000 ; I+=125000 )) ; do
./test.pl $I
echo -n "\n$I" >> result.dat
for f in times-*.dat ; do
echo -n " " >> result.dat
tail -n 1 $f | tr -d $'\n' >> result.dat
done
done
(columns: number of iterations, dict, dictdot and var):
250000 1.714012 1.441463 1.495100
375000 2.393011 2.043004 2.254167
500000 3.325472 2.770251 3.030824
625000 4.084556 3.918047 3.478740
750000 5.210081 4.626518 4.324522
875000 5.998363 5.376889 5.198982
1000000 6.473378 5.912451 6.061713
1125000 7.315470 6.733704 6.594582
1250000 8.408407 7.509624 7.035958
1375000 9.185902 8.262233 8.182109
1500000 10.123752 9.028213 9.046922
1625000 11.116502 9.148748 9.351769
1750000 12.067142 9.927794 10.077109
1875000 12.812228 11.509686 10.104975
2000000 13.705419 10.965901 12.190103
On the plot you can see that perfomance of dictdot and var is almost equal, so
you can use dictionaries and dot style freely, but should omit [] style if
possible.
No comments:
Post a Comment