The problem, though, is that I don't know how to put multiple DirLists
in a single window. Or is it plain impossible? (In that case: bye,
bye, stdwin. :-)
| either with or without multiple inheritance. Maybe this widget stuff
| isn't easy as I thought? The serious window systems [Andrew, X11,
| Windows3.1] are all too big, and the small ones [e.g. Rob Pike's one
| for Plan 9] suffer from lack of flexibility...
What I'm missing is a high level abstraction model for "accepted" user
interface objects, such as dialog boxes with elements such as a listbox.
| I also played around with it a little and found this, opening 7 or 8
| directories in a minute:
|
| |& time python TestDirList.py
| |
| |real 1:10.1
| |user 3.6
| |sys 0.8
| |&
|
| Now this is on a 33 MHz SGI Indigo, a real racing car. Is your
| machine slow or memory-starved? (14058 minor page faults looks like a
| lot to me).
I'm running on a 12 processor, 300Mb symmetry, and the load average is
below .5 with ~60 people. It's not the fastest machine, but certainly
nearly 100% processor utilization time (which means I used one of the
twelve processors almost exclusively; and note: the utilization time
can go as high as 1200%) is very suspicious...
| On the other hand it could be that your realloc() implementation is
| slow. If this is the case, building lists by appending elements to
Now *that* is an interesting assumption. I compiled in the optional
malloc library which implements the bucket algorithm. And lo and behold,
it is much better, but not close to what you show. It lookes like the
size of the directory is also pretty important... Maybe there are malloc
packages that are *really* smart? Here are some memory statistics:
Process: python pid: 8853 text_handle: 0x01b8f364 KB pte: 12
Values in K Bytes
Segment Virtual Resident Weighted RSS <- this is the only process
text 408 208 208.00 running, so there is nothing
data+bss 1236 880 880.00 to weigh (otherwise text
stack 12 12 12.00 would be shared)
shared 0 0 0.00
Total 1656 1100 1100.00
FYI: the paging algorithms on this system are set up to let processes
go up to 3Mb before *really* pruning them.
| the end one by one (as is done by os.listdir(), for example) may
| become an O(n**2) matter since realloc() is copying the entire array
| on each expansion. Most current malloc packages are cleverer than
| that, so I didn't bother to try and optimize this in the Python code,
| but if you're adventurous you could dive into the "listobject" source
| code and somehow extend the array used to hold the list in larger
| chunks.
No time for adventures right now. :-)
| Of course, I'd try to profile python first, just to get more insight
| (and yes, even on my system malloc is on top of the list).
OK, here is what I got (only the highest entries on the list):
%Time Seconds Cumsecs #Calls msec/call Name
21.6 16.58 16.58 23698 0.6997 newdictobject
15.6 11.97 28.56 23182 0.5165 eval_code
10.5 8.03 36.58 262848 0.0305 malloc
10.4 7.97 44.55 _mcount
4.8 3.70 48.25 262277 0.0141 free
3.4 2.58 50.83 582599 0.0044 strcmp
3.3 2.52 53.35 34252 0.0736 call_object
2.4 1.86 55.22 503 3.71 stat
1.8 1.36 56.58 94046 0.0145 settupleitem
1.8 1.35 57.93 183854 0.0074 dict2lookup
1.7 1.34 59.27 107153 0.0125 dict2insert
1.6 1.21 60.48 30 40.3 newclassobject
1.2 0.93 61.41 181919 0.0051 gettupleitem
1.1 0.84 62.25 877 0.96 getdictkey
1.0 0.75 63.00 158436 0.0047 gettuplesize
1.0 0.75 63.75 98732 0.0076 cmpobject
1.0 0.73 64.48 1182 0.618 putmsg
malloc is *not* on the top of the list. :-) Is this normal? Any other
input as to why it may be so cpu intensive?
Thanks,
-Jaap-
-- Jaap Vermeulen +--------------------------+ | Sequent Computer Systems | Internet : jaap@sequent.com | Beaverton, Oregon | Uucp : ...uunet!sequent!jaap +--------------------------+