[ Forum ]

Order by size, source or destination

Here you have suggestion for Supercopier and Ultracopier

Order by size, source or destination

Postby JoseNumal » Mon Oct 07, 2013 1:13 pm

Why not to do as in older versions and change the order of the list by size, source and destination?
JoseNumal
 
Posts: 1
Joined: Mon Oct 07, 2013 1:00 pm

Re: Order by size, source or destination

Postby alpha_one_x86 » Wed Oct 16, 2013 10:23 am

Hello,

Then I will repeat publicly again this point in English:
  • Short imply square complexity, that's mean all the newbies will try for bad reason sort their large list of millions of file, that's will result not usable application (days before start the copy).
  • That's do lot of code more, then possible new bug and stability problem
  • Bad reason given by the newbie:
    • That's optimize: wrong, that's slow down the copy because the hdd need seek on the data, need seek for the inode, and fragment the folder list

Cheer,
Developer of ImageUltracopier/ImageSupercopier and of the game ImageCatchChallenger
User avatar
alpha_one_x86
Site Admin
 
Posts: 1235
Joined: Sun Oct 26, 2008 9:09 am

Re: Order by size, source or destination

Postby Bryun » Thu Nov 13, 2014 11:48 am

I would personally like the ability to sort I prefer the old copier because of the ability to sort.

Yes the hard drive would have to seek making it slightly slower but it gives me the false but nice impression that it is copying faster, by starting with the smallest files first.
An application that takes days to start because of sorting is a very badly written application!

How can sorting take a lots of code you're sorting a list, displayed in a grid even.
Grids in most cases have the ability to sort built in.

The reasons given are weak at best sorting will not be so intensive and in cases where once does a million file copies.
They must expect some lag.

I bet most users do 1000 file copies at most.
Bryun
 
Posts: 1
Joined: Thu Nov 13, 2014 10:35 am

Re: Order by size, source or destination

Postby alpha_one_x86 » Thu Nov 13, 2014 12:15 pm

No the sort depends of the size of table to sort AND of the algo used. If you can do an algo with a complexity O(1) you can put your name into the history.
But you have sort by name (I can add by size if you use it, but will be like the sort by name local at the folder) during the listing (before put into the list).

No, can introduce bug, you need sort list taking care of multiple transfer started, reorder 2 list: the internal list, and emit a large list of change to update the displayed list (the view).
To have do the mechanism to sync the both list, it's shit to change that's part and product bug easily.

It's open source software, that's mean: you are allowed to demonstrate my error by doing a better code and I will integrate it.
I have noted to study it for the version 2 with a warning to the user.

I will not do the wish of the user at price of non-sens, large slow down or large bug creation.
Sort 1000 in memory can be fast, but the hdd will seek and the user will say: Ultracopier/Supercopier is very slow to do the copy. I know it, I was do the sort before. But due to multiple comment like that's, I have disabled it. I speak about hdd more slow, not the application, because it will seek.
Developer of ImageUltracopier/ImageSupercopier and of the game ImageCatchChallenger
User avatar
alpha_one_x86
Site Admin
 
Posts: 1235
Joined: Sun Oct 26, 2008 9:09 am


Return to Features requests



cron