Bug 150885

*** This bug has been marked as a duplicate of 43356 ***

There is no other way to provide a progress bar.
And not providing a progressbar isn't an option.

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_. 

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.

> 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.

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 ;)

> 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.

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.