faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: dcopserver memory usage
by Knut Stolze on Friday 20/Jul/2001, @19:42
|
Although I don't agree with the style of the original poster, I think he has a point on some respect.
In my system, I have 30 kdeinit processes running:
- 3x kicker: 3MB each
- noatun: 5MB (not active)
- 2x artsd: 3MB each (not active)
- 8x konsole: 1.5MB each
- 3x kdesktop: 1MB each
- various other things
This is just the memory used on the heap. I think for each of these, this is quite a lot in terms of memory consumption. Also, for some I cannot understand why multiple processes are running, e.g. artsd. Maybe these are threads...
What really scares me, though, is that there is a lot of infrastructure missing:
- no memory management to track leaks (after 2 months being logged in, even the smallest leak becomes a big problem)
- no tracing
For instance, 'artsd' likes produce some deadlock in the kernel (at least that's my theory) and wastes a lot of resources that way. But there is no other way to support the developer in finding the problem that to say: "there is a problem". How are the odds that this will be fixed? Not very good, I'd say. I was hoping that this particular problem will be fixed in 2.2 (I reported it a while ago), but it still appears in beta1. Having a trace facility in place would help very much by being able to take a trace when the problem occurs.
This is a common feature in commercial applications. Why not in something as complex as KDE?
Knut |
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
