Bug 150885 - Shouldn't count number of folders/files for delete operation when number exceeded some reasonable value
Summary: Shouldn't count number of folders/files for delete operation when number exce...
Status: RESOLVED DUPLICATE of bug 43356
Alias: None
Product: konqueror
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-16 10:05 UTC by Vladimir Kokovic
Modified: 2008-09-18 10:59 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Kokovic 2007-10-16 10:05:38 UTC
Version:            (using KDE KDE 3.5.8)
Installed from:    Ubuntu Packages
OS:                Linux

I've made terrible mistake trying to delete my old Open SuSe directory tree using konqueror file manager !

FYI that tree is about 50000 folders, 500000 files and about 15.8GB.

And konqueror started to count folders/files !!!

After 20 minutes, finally number of objects is known.

After 10 minutes konqueror finished my original request to remove the tree.

Do we need additional comment ?

Best regards,
Vladimir Kokovic, DP senior, Europe, Belgrade, Serbia
Comment 1 Jaime Torres 2008-06-10 16:54:38 UTC

*** This bug has been marked as a duplicate of 43356 ***
Comment 2 David Faure 2008-09-16 17:44:46 UTC
There is no other way to provide a progress bar.
And not providing a progressbar isn't an option.
Comment 3 Maciej Pilichowski 2008-09-16 18:03:34 UTC
Ok, then I ask -- what the user wants progress bar for?

Note that having progress bar requires:
a) twice time needed for delete
b) infinitive time more for cancel

I doubt there is anybody who would like to waste time using computer. If I want/have to delete files I want to delete them -- _fast_. 
Comment 4 David Faure 2008-09-17 10:20:03 UTC
The user wants a progressbar, well, to see the progress of the operation - nothing new there, there's a progressbar in all systems I can think of.
a) Twice the time is only true for 3000 files. If you delete 3 big files, then the progressbar is very useful and didn't cost that much time to set up.
b) I don't understand what you mean about cancel. Anyway.

Maybe after 100 we should stop counting and use a bouncing progressbar instead.
Comment 5 Maciej Pilichowski 2008-09-17 11:23:19 UTC
> The user wants a progressbar, well, to see the progress of the operation 

I am not sure of that -- user wants to see that something is going for sure but I doubt there is so much need to see "I am at 20% on deleting files". Rather to see what is deleted. Especially if you tell user she/he has to wait more (with progres bar).

ad.a) if you have 3 files, deletion is a blink of an eye, what do you need progress bar there for?
ad.b) I assumed you count files before you show the confirmation dialog

> Maybe after 100 we should stop counting and use a bouncing progressbar
> instead.

Indeed. However it would be good to have exact estimation how much time is wasted on handling progress bar. I remember awful drawback with K3b -- it was so slow when adding files to burn and it appeared the handling progress bar caused that.

So:
1) how much does it take to delete 3 files
1.1) 3000 files
2) how much does it take to count 3 files, delete them while showing progress bar
2.1) 3000 files

If you ask me I would opt (at least for me and users I "manage") to show just simple rotate/bouncing/anything progress bar (thus without counting) plus info maybe about what is being deleted.
Comment 6 David Faure 2008-09-17 14:27:31 UTC
Doing timings made me optimize the code :)
In the case of 1000 files (in the same directory), what takes most time was that "is this a file or a directory" because it was delegated to kio_file. Adding a fast path, I just improved the performance by a factor 25 (!)

Commit r861889.
 before: 4177 ms with independent jobs, 3860 ms with one job
 after: 1010 ms with independent jobs, 150 ms with one job.
End users selecting 1000 files in konqueror fall into the "with one job" category, so this is a 25-times speedup.

To answer some earlier points:
ad.a) Deleting 3 _huge_ files (like 5GB movies I record on TV) takes a good 20 seconds; the progress bar is very very useful.
ad.b) Nope.

Let's distinguish two things. 

Use case A) you select 1000 files from the same directory (e.g. with Ctrl+A) and press Del: you get a confirmation dialog with 1000 items in it, and then a KIO job takes care of deleting those files (in 150ms, now ;)

Use case B) you select ONE directory, and press Del. The confirmation dialog shows only one name. But the KIO job has to do a recursive listing to know what it will have to delete - and also uses that information to show a progress dialog. I was wrong earlier, I can't skip that step, I need to know what to delete ;)
Comment 7 Maciej Pilichowski 2008-09-17 15:52:29 UTC
> Adding a fast path, I just improved the
> performance by a factor 25 (!)

Great news, thank you David!

> To answer some earlier points:
> ad.a) Deleting 3 _huge_ files (like 5GB movies I record on TV)
> takes a good 20 seconds;

Hmm... this is odd -- in case you destroy files it does not matter how big files are. In case when you move the file to trash it does not matter how file big is either :-) 

So here is something strange.

> the progress bar is very very useful. 

David, I am not that sure. Let's do some math -- you say it takes 20 seconds, let's say 21 then for each file it takes 7 seconds.
It means I will see

0% for 7 seconds
#### 33% for another 7 seconds
######## 66% for another 7 seconds

Now -- what is benefit of staring for 7 seconds at:
#### 33%
?

Progress bar has purpose if it is on the move -- if it only makes huge steps and each step takes a lot of time this is not information useful for the user. Why? Because app may as well be frozen and you won't tell the difference -- information for user is feedback that something is going on -- deleting.

So even the old rotate unix progress indicator \-/| is better in such case.

Was it window with this deletion animation, filename and nothing more. This is something I have in mind which would be much faster.

> ad.b) Nope.
>
> Let's distinguish two things.
>
> Use case A) you select 1000 files from the same directory (e.g.
> with Ctrl+A) and press Del: you get a confirmation dialog with 1000
> items in it, and then a KIO job takes care of deleting those files
> (in 150ms, now ;)
>
> Use case B) you select ONE directory, and press Del. The
> confirmation dialog shows only one name. But the KIO job has to do
> a recursive listing to know what it will have to delete - and also
> uses that information to show a progress dialog. I was wrong
> earlier, I can't skip that step, I need to know what to delete ;)

This looks bad -- so the counting takes place _before_ showing the dialog. IMHO it should be shown immediately.

Summing up -- I opt for removing counting at all, showing confirmation dialog right away, getting rid of progress bar, introducing animation progress only ("it is working"), showing what is being deleted while deleting it.

This would speed up things again because it file has to be accessed only once, not twice. I/O here is the bottleneck so the less disk access, the better. Comparing this to graphic, you can say animation (progress) is cheap.
Comment 8 David Faure 2008-09-18 10:59:53 UTC
When deleting files it appears to matter how big they are, at least with LVM.
What is benefit of staring for 7 seconds at 33%? To know that it's going to take another 14 seconds before this operation is done. So you can relax and sit back rather wonder why those damn files just don't disappear.

> the counting takes place _before_ showing the dialog.
No. Just try it. You can see the dialog counting and then deleting. Well, you COULD see. With my fixes, you have no time to see it anymore.
Deleting while listing is not possible with the kioslave abstraction; listing and deleting are two separate operations. But let's not keep making guesses about what is slow - the KIO job level is really fast now, so the counting isn't the problem, the remaining performance issue is in KDirModel as mentionned in 43356, I am almost done fixing that.