problem with KIO::NetAccess and KDirLister/KFileTreeView

[Josef Weidendorfer]

On Tuesday 15 October 2002 21:35, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [Hmm, I still had this in my drafts folder, from some time ago, I forgot to
> send it.]

Yeah, this seems almost outdated...

> On Tuesday 08 October 2002 13:02, Josef Weidendorfer wrote:
> > Of course "delaying and compressing" is needed in KDirWatch as the above
> > is not generally possible. Note that even delivering these huge amounts
> > of "changed" events only to KDirWatch can be very CPU-intensive when the
> > notifications are created by the kernel. The current LINUX DNOTIFY
> > implemention sends a signal on every file change (e.g. each write()
> > system call). Here, the "delaying and compression" should be already done
> > in the kernel.
>
> I agree. Is there any chance of this happening?

No idea... Can you ask some Kernel developer?
Or I will look who did the last patch to the dnotify support in 2.4.19...

> > We need 2 time interval values:
> ...
> Ok, this is more complex that what I thought of (a simple short max delay
> from the first event). But indeed this reacts nicer on long copy
> operations.

As I said in my last mail, I need to implement "watchFiles" before. Otherwise 
some FAM events can't be delayed...

> > Or some tracing with cachegrind and analysing with KCachgrind. BTW, are
> > you using it sometimes (my baby, hehe)?
>
> Not yet - KWord seemed too big for it, last time I tried. (cachegrind
> exited after eating all available memory).

With kword from Suse 8.1 (KWord 1.2) cachegrind uses up 138 MBs after starting 
KWord with an empty file (no debug symbols in KDE/QT). After quitting, the 
dumped trace file has around 4 MB and cachgrind says 1 G instruction refs ;-) 
Not that much difference to konqueror.
Of course this can change a lot with debug info. I suppose I can do nothing 
about this...

> > OT: I should do a KPart for
> > inode/directory showing space partitioning on your harddisc using my
> > TreeMap widget. As (tiny, like 50 lines) application it's already on my
> > HD: It's unbelievable how fast you see your space wasters...
>
> Yes this would be cool. I still have to use "du" for this.

See attached TGZ :-)
I hope 23kB are OK for this mailing list... Today I added asynchronous 
updating in the background and persistant caching of dir sizes for dirs with 
more than 500 files. At the moment, everything is available with the context 
menu...
For a KPart, I would like to have the normal Konqueror context menu for files.
The treemap also supports QPixmap aside the texts, so one can add the
mimetype pixmap for a file...

What do you think about it?

> > Have you NFS working on this system (it uses the portmapper, too)?
>
> Yup, works ok.

Then I don't understand the FAM problem...

> > > But Konqueror (which needs to notice files growing) would then be
> > > stat'ing every file it's showing? This could be a lot of files. Do we
> > > really want that?
> >
> > If you have FAM running, the FAM daemon already does this :-)
>
> Hmm, I thought there was a kernel part of it....

I thought that typical FAM installations come without kernel support...
But you can see what fam is doing by starting it with "fam -d" in a xterm.

> > You say: Konqueror needs to notice files growing. So there's no real way
> > around this, is there? And stat() in LINUX is really fast in my
> > experience (they put a lot of effort into this).
>
> It's very slow over NFS, but that's another story ;)

And that's the real reason to use FAM. On the NFS server machine, a fam daemon 
needs to running and everything will be quite fast again.

> Hmm. I can see from here the reports from people who notice that konqueror
> is stat'ing every file it's showing, many times per second.... (maybe a

I don't think this is too bad. We do already enough periodic watching.
We need to test it in CVS Head for a while, and if no developers has problems 
with it, I think the enduser will not have problems, too.

> much longer period like 1-5 seconds would be enough, but it gives an
> impression of slowness....)

Yes, that's a possibility. And if a user wonder about the slowness, simple 
say: Use FAM or DNOTIFY!

Josef

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fsview.tgz
Type: application/x-tgz
Size: 23046 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021016/acb14b9a/attachment.bin>