 |
|
| node: | Re[3]: 25.10.2012-19:17:41 |
| template: | 4 |
| parent: | Re[2]: 25.10.2012-19:17:41 |
| owner: | w |
| viewed by: | |
| created: | 25.10.2012 - 20:36:15 |
|
cwbe coordinatez: 101 63540 63709 6893414 6893464 6893472 6893494 ABSOLUT KYBERIA |
| permissions | |
| you: | r, |
| system: | public |
| net: | yes |
total descendants::9
total children::1
to ci je compact folders automaticke od tej verzie by som si netrufal tvrdit.
kazdopadne problem je jednoduchy. volne si to predstav tak, ze mas papier a na nom poznamky, co mas robit. ked prijde nova, napises ju na koniec, ked nejaku vykonas, preciarknes ju. taketo robi aj ten mailbox file. ked don dojde novy mail, napise ho nakoniec. ked nejaky zmaze, "zacmara ho" ale zo suboru fyzicky zmiznut nemusi. rovnako ako to mas s Tvojim poznamkovym papierom.
na papieri sa Ti casom hromadia zacmarane miesta, ale priestor po tych zacmaranych spontanne nepribudne, inak povedane, miesto na papieri je zabrate a nepouzitelne. a take to zostane az kym ... neprepises svoje poznamky na novy papier. tam uz nebudu cmaranice a bude tam len to, co tam byt ma. inak povedane, kym sa s mailboxom nieco neudeje, cely slavny mailboxovy file moze zaberat povedzme 1GB a pritom obsahovat len jeden 1kb mail.
az kym sa nieco neudeje ... a to je to compact folders.
a to autocompact folders tam je, ale treba ho mat aj zapnute. rovnako je tam napisany nejaky threshold, teda hodnota typu "ked uspora dosiahnuta spustenim compact folders dosiahne hodnotu aspon *threshold*, automaticky spusti compact folders".
znie to ako absolutna hovadina, ale nie je to, aj ked navonok to tak neposobi. predstav si, ze mas mailbox o velkosti povedzme 2GB, s ktorym aktivne pracujes a malo by sa "compact folders" robit po kazdom zmazani. ono sa to nezda, ale presuvat 2GB dat nie je uplne casovo nenarocna operacia a takto by si mohol polahky docielit, ze zmazes mail, pockas zodesat sekund, zmazes dalsi, pockas inych zodesat sekund. ano, dalo by sa to ciastocne optimalizovat, ze "ved spravim to az ked vypnem aplikaciu" / ... napadov vela, kazdopadne sposobuje to zdrzanie, preto ten prah. asi tolko.
kazdopadne problem je jednoduchy. volne si to predstav tak, ze mas papier a na nom poznamky, co mas robit. ked prijde nova, napises ju na koniec, ked nejaku vykonas, preciarknes ju. taketo robi aj ten mailbox file. ked don dojde novy mail, napise ho nakoniec. ked nejaky zmaze, "zacmara ho" ale zo suboru fyzicky zmiznut nemusi. rovnako ako to mas s Tvojim poznamkovym papierom.
na papieri sa Ti casom hromadia zacmarane miesta, ale priestor po tych zacmaranych spontanne nepribudne, inak povedane, miesto na papieri je zabrate a nepouzitelne. a take to zostane az kym ... neprepises svoje poznamky na novy papier. tam uz nebudu cmaranice a bude tam len to, co tam byt ma. inak povedane, kym sa s mailboxom nieco neudeje, cely slavny mailboxovy file moze zaberat povedzme 1GB a pritom obsahovat len jeden 1kb mail.
az kym sa nieco neudeje ... a to je to compact folders.
a to autocompact folders tam je, ale treba ho mat aj zapnute. rovnako je tam napisany nejaky threshold, teda hodnota typu "ked uspora dosiahnuta spustenim compact folders dosiahne hodnotu aspon *threshold*, automaticky spusti compact folders".
znie to ako absolutna hovadina, ale nie je to, aj ked navonok to tak neposobi. predstav si, ze mas mailbox o velkosti povedzme 2GB, s ktorym aktivne pracujes a malo by sa "compact folders" robit po kazdom zmazani. ono sa to nezda, ale presuvat 2GB dat nie je uplne casovo nenarocna operacia a takto by si mohol polahky docielit, ze zmazes mail, pockas zodesat sekund, zmazes dalsi, pockas inych zodesat sekund. ano, dalo by sa to ciastocne optimalizovat, ze "ved spravim to az ked vypnem aplikaciu" / ... napadov vela, kazdopadne sposobuje to zdrzanie, preto ten prah. asi tolko.