← Back to branch summary

~ubuntu-branches/ubuntu/natty/pytables/natty-updates

« back to all changes in this revision

Viewing changes to bench/undo_redo.txt

  • Committer: Bazaar Package Importer
  • Author(s): Alexandre Fayolle
  • Date: 2006-06-28 10:45:03 UTC
  • mfrom: (1.2.1 upstream)
  • mto: This revision was merged to the branch mainline in revision 5.
  • Revision ID: james.westby@ubuntu.com-20060628104503-cc251q5o5j3e2k10
  * Fixed call to pyversions in debian/rules which failed on recent versions 
    of pyversions
  * Fixed clean rule in debian/rules which left the stamp files behind
  * Acknowledge NMU
  * Added Alexandre Fayolle to uploaders

Show diffs side-by-side

added added

removed removed

Lines of Context:
bench/undo_redo.txt
 
1
Benchmarks on PyTables Undo/Redo
 
2
================================
 
3
 
 
4
This is a small report for the performance of the Undo/Redo feature in
 
5
PyTables.
 
6
 
 
7
A small script (see undo_redo.py) has been made in order to check
 
8
different scenarios for Undo/Redo, like creating single nodes, copying
 
9
children from one group to another, and creating attributes.
 
10
 
 
11
Undo/Redo is independent of object size
 
12
---------------------------------------
 
13
 
 
14
Firstly, one thing to be noted is that the Undo/Redo feature is
 
15
independent of the object size that is being treated. For example, the
 
16
times for 10 objects (flag -n) each one with 10 elements (flag -s) is:
 
17
 
 
18
$ time python2.4 undo_redo.py -n 10 -i 2 -s 10 data.nobackup/undo_redo.h5
 
19
Time for Undo, Redo (createNode): 0.213686943054 s,  0.0727670192719 s
 
20
Time for Undo, Redo (createNode): 0.271666049957 s,  0.0740389823914 s
 
21
Time for Undo, Redo (copyChildren): 0.296227931976 s,  0.161941051483 s
 
22
Time for Undo, Redo (copyChildren): 0.363519906998 s,  0.162662982941 s
 
23
Time for Undo, Redo (setAttr): 0.208750009537 s,  0.0732419490814 s
 
24
Time for Undo, Redo (setAttr): 0.27628993988 s,  0.0736088752747 s
 
25
 
 
26
real    0m5.557s
 
27
user    0m4.354s
 
28
sys     0m0.729s
 
29
 
 
30
Note how all tests take more or less the same amount of time. This is
 
31
because a move operation is used as a central tool to implement the
 
32
Undo/Redo feature. Such a move operation has a constant cost,
 
33
independently of the size of the objects. For example, using objects
 
34
with 1000 elements, we can see that this does not affect the Undo/Redo
 
35
speed:
 
36
 
 
37
$ time python2.4 undo_redo.py -n 10 -i 2 -s 1000 data.nobackup/undo_redo.h5
 
38
Time for Undo, Redo (createNode): 0.213760137558 s,  0.0717759132385 s
 
39
Time for Undo, Redo (createNode): 0.276151895523 s,  0.0724079608917 s
 
40
Time for Undo, Redo (copyChildren): 0.308417797089 s,  0.168260812759 s
 
41
Time for Undo, Redo (copyChildren): 0.382102966309 s,  0.168042898178 s
 
42
Time for Undo, Redo (setAttr): 0.209735155106 s,  0.0740969181061 s
 
43
Time for Undo, Redo (setAttr): 0.279798984528 s,  0.0770981311798 s
 
44
 
 
45
real    0m5.835s
 
46
user    0m4.585s
 
47
sys     0m0.736s
 
48
 
 
49
 
 
50
Undo/Redo times grow linearly with the number of objects implied
 
51
----------------------------------------------------------------
 
52
 
 
53
Secondly, the time for doing/undoing is obviously proportional
 
54
(linearly) to the number of objects that are implied in that process
 
55
(set by -n):
 
56
 
 
57
$ time python2.4 undo_redo.py -n 100 -i 2 -s 10 data.nobackup/undo_redo.h5
 
58
Time for Undo, Redo (createNode): 2.27267885208 s,  0.779091119766 s
 
59
Time for Undo, Redo (createNode): 2.31264209747 s,  0.766252040863 s
 
60
Time for Undo, Redo (copyChildren): 3.01871585846 s,  1.63346219063 s
 
61
Time for Undo, Redo (copyChildren): 3.07704997063 s,  1.62615203857 s
 
62
Time for Undo, Redo (setAttr): 2.18017196655 s,  0.809293985367 s
 
63
Time for Undo, Redo (setAttr): 2.23039293289 s,  0.809432029724 s
 
64
 
 
65
real    0m48.395s
 
66
user    0m40.385s
 
67
sys     0m6.914s
 
68
 
 
69
 
 
70
A note on actual performance and place for improvement
 
71
------------------------------------------------------
 
72
 
 
73
Finally, note how the Undo/Redo capability of PyTables is pretty
 
74
fast. The next benchmark makes 1000 undo and 1000 redos for
 
75
createArray:
 
76
 
 
77
$ time python2.4 undo_redo.py -n 1000 -i 2 -t createNode -s 1000 data.nobackup/undo_redo.h5
 
78
Time for Undo, Redo (createNode): 22.7840828896 s,  7.9872610569 s
 
79
Time for Undo, Redo (createNode): 22.2799329758 s,  7.95833396912 s
 
80
 
 
81
real    1m32.307s
 
82
user    1m16.598s
 
83
sys     0m15.105s
 
84
 
 
85
i.e. an undo takes 23 milliseconds while a redo takes 8 milliseconds
 
86
approximately.
 
87
 
 
88
The fact that undo operations take 3 times more than redo is probably
 
89
due to how the action log is implemented. The action log has been
 
90
implemented as a Table object, and PyTables has been optimized to read
 
91
rows of tables in *forward* direction (the one needed for redo
 
92
operations). However, when looking in *backward* direction (needed for
 
93
undo operations), the internal cache of PyTables is counterproductive
 
94
and makes look-ups quite slow (compared with forward access).
 
95
Nevertheless, the code for Undo/Redo has been optimized quite a bit to
 
96
smooth this kind of access as much as possible, but with a relative
 
97
success. A more definitive optimization should involve getting much
 
98
better performance for reading tables in backward direction. That
 
99
would be a major task, and can be eventually addressed in the future.
 
100
 
 
101
 
 
102
Francesc Altet
 
103
2005-03-10