Új hozzászólás Aktív témák

• floatr veterán

  #5234

  #5230 tothpetya

  2014-03-25 15:34:31

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #5230 tothpetya

  #5230 tothpetya

  Ezzel tisztában vagyok. Azért kérdeztem, hogy nem tudtok-e olyan megoldást, aminek nem kell végigjárni az egész fát. De akkor ezek szerint nem.

  Ennél lényegesen gyorsabb szvsz intézőben sem lesz, max ha másik file rendszert használsz. Másoláskor csak annyit tehetsz, hogy bejárod a fát. Mozgatáskor van annyi előnyöd, hogy egyazon partícióba nincsen fizikai mozgatás, csak a megfelelő bejegyzés(ek) átírása.

  Kis file-ok másolásakor nem az USB3 teljesítménye igazán a szűk keresztmetszet, hanem a filerendszerbeli módosítások okozta pozicionálások. Sokszor a puffert sem olvassa tele az első lépésben sem.

• Aethelstone addikt

  #5231

  #5230 tothpetya

  2014-03-25 15:25:48

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #5230 tothpetya

  #5230 tothpetya

  Ezzel tisztában vagyok. Azért kérdeztem, hogy nem tudtok-e olyan megoldást, aminek nem kell végigjárni az egész fát. De akkor ezek szerint nem.

  Nem a fa végigjárása a nagy idő, hanem a fájlnyitás+másolás+zárás.

• Aethelstone addikt

  #5229

  #5228 tothpetya

  2014-03-25 15:19:17

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #5228 tothpetya

  #5228 tothpetya

  USB3-as sebességhez én kicsit lassúnak érzem.

  Az egy dolog, hogy Te hogyan érzed Egyrészt nagyban függ a másolás sebessége a fájlok mennyiségétől és méretüktől is. Sok kicsit szart tök lassan másol. Ugye van megnyitási idő, másolási idő, lezárási idő. X fájl esetén ez pontosan Xszer annyi, mint mondjuk 1 fájl esetén.

• Aethelstone addikt

  #5227

  #5226 tothpetya

  2014-03-25 15:10:11

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #5226 tothpetya

  #5226 tothpetya

  Akkor próbálom vázolni újra a helyzetet. Van egy könyvtáram legyen főkönyvtár a neve. Ebben van körülbelül 10.000 almappa. Ezekben a mappákban változó számú fájlok vannak. Pl 1-20-ig. Fájlok nem törlődnek, illetve NEM módosulnak. Naponta fel kell ezt a főkönyvtárat másolni egy HDD-re (amin rajta vannak az előző napi fájlok). A lényeg, hogy csak azt másoljuk fel, ami még nincs fent.

  Akkor azt mondjátok, hogy az exist() vizsgálat gyorsabb, mint a FileAlreadyExistsException kivétel dobása NIO 1.7-es másolással?

  Azt mondod, hogy 15 perc alatt végez a 10K almappa vizsgálattal + másolás? Mit akarsz még ezen gyorsítani?

• Aethelstone addikt

  #5223

  #5222 tothpetya

  2014-03-25 14:48:51

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #5222 tothpetya

  #5222 tothpetya

  Nem baj, azért írtam ide, mert szeretnék minél több nézőpontot megismerni.

  Az általam említett kódban is csak azt másoljuk ami nincs még meg (a fájlok nem változnak létrehozás után).

  Nos, azt írod, hogy mappaméretet hasonlítasz össze és ha ugyanakkora, akkor nem lép bele. Ez jó, de kevés. Van egy fájlod, amiben ez van: "Jo napot kivanok" és egy másik, amiben ez: "Jo kapot kivakok"

  Méretilag koppra egyezik a két fájl, de az egyik más időpontban lett módosítva. Ezért csak a méret nem elég, módosítás dátuma is kell. Ezt a kolléga kódja megcsinálja. Másrészt meg méret meghatározásához úgy is bele kell menned és fel kell olvasnod a benne lévő fájlok metaadatait.

• Aethelstone addikt

  #5221

  #5220 tothpetya

  2014-03-25 14:30:20

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #5220 tothpetya

  #5220 tothpetya

  Köszi szépen, majd letesztelem. Viszont nem értem ez miért lenne gyorsabb, mint az alap kód?

  Bocs, hogy belepofázok, de annyival gyorsabb tud lenni, hogy nem másol mindent, hanem csak azt, ami változott. Ahogy a kolléga a hozzászólásában meg is fogalmazta. Gyakorlatilag deltát másolni mindig gyorsabb, ha feltételezzük, hogy nem változik minden.

• floatr veterán

  #5219

  #5218 tothpetya

  2014-03-25 11:39:45

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #5218 tothpetya

  #5218 tothpetya

  Ez kódban kb, hogy nézne ki, mert nem igazán értem, hogy mit szeretnél mondani.

  Ilyesmire gondoltam, nem teszteltem:

  private static void prepare(File src, File dest, List<File> from, List<File> to) {
  File f, d;
  for (String p : src.list()) {
  f = new File(src, p);
  if (f.isDirectory()) {
  d = new File(dest, p);
  d.mkdir();
  prepare(f, d, from, to);
  } else {
  from.add(f);
  to.add(new File(dest, p));
  }
  }
  }
  
  private void copy(List<File> from, List<File> to) {
  Iterator<File> itrFrom = from.iterator();
  Iterator<File> itrTo = to.iterator();
  File ff, ft;
  int size = from.size();
  for (int i = 0; itrFrom.hasNext() && itrTo.hasNext(); i++) {
  ff = itrFrom.next();
  ft = itrTo.next();
  if (ff.length() != ft.length() || ff.lastModified() < ft.lastModified()) {
  Files.copy(ff, ft);
  }
  
  // show progress: i/size
  }
  }

• floatr veterán

  #5216

  #5215 tothpetya

  2014-03-25 09:39:16

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #5215 tothpetya

  #5215 tothpetya

  Sziasztok!

  Kellene egy kis segítség nekem. Van egy egyszerű Java program, ami csak annyit csinál, hogy sok kis fájlt másol egyik helyről a másikra. Naponta. Mivel elég sok van, ezért úgy kellene megoldani, hogy csak azokat másolja ami már nincs meg a másik helyen. Ezt a következőképpen oldottuk meg:

  //Másolás függvénye:
  public void masolas(File src, File dest)
  throws IOException {
  //Meg vizsgáljuk, hogy mappa-e:
  if (src.isDirectory()) {
  //Megpróbáljuk létrehozni a mappát (ha van, akkor nem csinál semmit)
  dest.mkdir();
  //Listába rendezzük a mappa tartalmát:
  String files[] = src.list();
  //Majd egyesével végigmegyünk rajta:
  for (String file : files) {
  //Elkészítjük a fájlokat:
  srcFile = new File(src, file);
  destFile = new File(dest, file);
  //Rekurzív másolás:
  masolas(srcFile, destFile);
  }
  } else {
  try {
  Files.copy(src.toPath(), dest.toPath());
  System.out.println("Másolás: " + src);
  } catch (FileAlreadyExistsException ex) {
  System.out.println("Ez a fájl már meg van: " + src);
  }
  }
  }

  Viszont így is körülbelül 15 perc alatt megy végig a fájlokon, ha meg van minden akkor is. Meg kellene gyorsítani. Ötletek?

  Kb így néz ki a struktúra:

  mappaneve1: fajl1, fajl2, fajl3
  mappaneve2: fajl1
  mappaneve3: fajl1 ... faj10

  Szóval van olyan mappa ami 10-15 fájlt is tartalmaz és ezek közül sok valószínűleg nem is változik. Arra gondoltam, hogy át kellene úgy alakítani, hogy először megnézi a mappa méretét és ha stimmel a kettő, akkor "bele se lép". Szerintetek ez kivitelezhető? Vagy azt is csak úgy tudja, hogy belelép és összeszámolja a tartalmát. Ha ez nem életképes, akkor valakinek van más ötlete?

  Amikor egy alkalmazás lekérdezi a könyvtár méretét, akkor vagy shell parancsot használ (ami nem túl hordozható megoldás), vagy szépen végignyálazza rekurzívan a belsejét. A leggyakrabban azt szokták csinálni, hogy a megadott útvonalat első körben beolvassák egy nagy listába, és minden elemhez tárolják a méretét, és az utolsó módosítás dátumát. A könyvtárakat nem is feltétlenül szükséges ebben a listában tárolni, mert az mkdirs rekurzívan létrehozza azokat, vagy esetleg a feltérképezéskor érdemes lehet már eleve létrehozni őket. Aztán második menetben összehasonlítod a méret/dátum értékeket, és ha nem stimmel, akkor másolsz. Akkor már csak a lista elemein kell végigfutni, és tudsz becsülni végrehajtási időt is.

Új hozzászólás Aktív témák