Review Request: Fix KIO listDir entries batching

[Pino Toscano]

> On Nov. 29, 2012, 7:48 p.m., Pino Toscano wrote:
> > kioslave/file/file_unix.cpp, line 363
> > <http://git.reviewboard.kde.org/r/107520/diff/1/?file=96853#file96853line363>
> >
> >     This would be QFile::decodeName, not QString::fromLocal8Bit... but you don't need it either, since you have "path" already.
> 
> Mark Gaiser wrote:
>     Am i allowed to use the path variable? Considering that it isn't decoded..
>     Also, i can't use QFile::decodeName directly because it returns a QByteArray. QDir::setCurrent wants to have a QString. Usually that wouldn't be an issue. However, there are some compile parameters set that forbids me from doing that so i have to use the QString::from... functions or the data variable.

> Am i allowed to use the path variable? Considering that it isn't decoded..

Uh? "path" is a QString, hence unicode.

> Also, i can't use QFile::decodeName directly because it returns a QByteArray.

Apparently, reading the documentation is hard:
    static QByteArray encodeName(const QString &fileName);
    static QString decodeName(const QByteArray &localFileName);

> QDir::setCurrent wants to have a QString

Yes, an unicode string, and it will do the right job to decode it in the proper way for the current OS / file system.


- Pino


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107520/#review22785
-----------------------------------------------------------


On Nov. 29, 2012, 7:33 p.m., Mark Gaiser wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107520/
> -----------------------------------------------------------
> 
> (Updated Nov. 29, 2012, 7:33 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Description
> -------
> 
> listDir is batching only in a vague manner. It required to have details set to something bigger then 0 and required to know the amount of files that where going to be send. Even then it was fixed to broadcast only the first 100 entries followed by _everything_ that comes after it. For more details, look at the diff. If you did happen to do a request with details set at 0 (thus only the filename and filetype are stored) then a different code path was taken where it wasn't even possible to batch.
> 
> I changed this to do time based batching. Now it broadcasts all the entries it currently has after 300ms have been passed. In normal situations on the local file system that means that you will never see batching. You will start to see them if you hit folders with 10.000+ entries in then (for a SSD that is). For the slower HDD drives you probably see more batching.
> 
> In the worst case scenario you could find yourself in the situation that 1 entry is broadcasted every 300ms. That is only on very slow external devices or internet places.
> 
> The advantage of batching (just repeating that here since it's currently not working in any KDE app) is that you can start showing results to the user without all the results being in. This gives the user a "feeling" that it's fast even though KIO might still be working hard to get all entries in. Dolphin is one app in particular that can really make use of this. Currently it doesn't do that. IT waits till all the results are in.
> 
> While working on this, i also updated the style of the FileProtocol::listDir function and greatly simplified how it lists the directory. Now the actual listing just follows one code path instead of one for details 0 and one for the rest.
> 
> I'd like to get this in kdelibs for KDE 4.10 because it is a bugfix even though there is no bug report.
> 
> 
> Diffs
> -----
> 
>   kio/kio/slavebase.h 0bdb146 
>   kio/kio/slavebase.cpp 8f8ff03 
>   kioslave/file/file_unix.cpp 2b47b7c 
> 
> Diff: http://git.reviewboard.kde.org/r/107520/diff/
> 
> 
> Testing
> -------
> 
> I tested this in various ways:
> (SSD) 100.000 entries in a folder with details set to 0: 1 signal with all entries
> (SSD) 100.000 entries in a folder without details set (all info): 2 or 3 signals each with between 20.000 - 50.000 entries
> (slow ftp) ftp://ftp.mirror.aarnet.edu.au/pub/archlinux/extra/os/x86_64/ results start slowly with 20 - 50 per signal and quickly climb up.
> Ran the kio test cases. Apparently i have a "failed" for kio-krununittest, a testcase that David Faure has fixed if i'm right.
> Updated the documentation to not mention the total files anymore. KioSlaves can still set it, but it's just unused for the listDir now.
> Last, running with this now and i haven't seen any issues so far.
> 
> 
> Thanks,
> 
> Mark Gaiser
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20121129/9037184e/attachment.htm>