Когда Windows копирует файлы
раскрыть ветку (18)
раскрыть ветку (16)
раскрыть ветку (10)
раскрыть ветку (9)
думаешь? при копировании больших объемов информации (как раз когда пригодилось бы точное время), основное снижение скорости идет на множестве мелких файлов. Для того, чтобы выдать более-менее точное время - нужно просканировать всю структуру копируемого файла. И если там очень большая структура, это сканирование занимает довольно продолжительное время. Классический пример - попробуй посмотреть свойства папки windows. Ты увидишь, что объем данных набирается не сразу. Это как раз то время, которое требуется на полное сканирование файлов.
раскрыть ветку (8)
раскрыть ветку (7)
А как насчет фрагментации? Ее как-то тоже нужно учитывать, особенно для HDD а не SSD. Короче, это очень сложная задача.
раскрыть ветку (1)
раскрыть ветку (4)
ну какбэ ни один лишний файл анализироваться не будет.
только копируемая тобой папка и все вложенные.
только копируемая тобой папка и все вложенные.
раскрыть ветку (2)
Думаю дело не в этом. Вряд ли ребята из Редмонда стали бы использовать такой банальный алгоритм (который может еще и упасть с переполнением стека) для копирования. Я думаю, неопределенность вызвана тем, что нельзя точно сказать сколько времени займет копирование, не скопировав файл (особенно когда файлов много и они мелкие). С одной стороны, вроде бы там всего 4 килобайта данных, и копирование тысячи таких файлов не должно занять более двух минут. Но файловая система тратит нехилое количество времени на создание файла и реорганизацию файловой таблицы, и вот уже перспективы не такие радужные, прогноз становится все более мрачным. Но вот череда мелких файлов проходит, и прогноз времени снова становится близким к реальности.
раскрыть ветку (4)
раскрыть ветку (3)
Нуу я бы не был так уверен. Действительно, в программировании есть тенденция, когда простая структура кода позволяет сократить риск возникновения багов / увеличивает читабельность кода, и его поддерживаемость. Об этом говорит принцип KISS. Однако это не означает, что все, написанное просто и понятно - априори работает быстро. Совсем не означает. Скорее даже наоборот. Для примера возьмем общеизвестные алгоритмы, сортировки и поиска кратчайшего пути. Банальный метод сортировки, изучаемый школьниками в начале пути, bubblesort, гораздо проще и банальнее, чем quicksort. Также как банальные рекурсивные алгоритмы DFS / BFS проще и понятнее алгоритма Дейкстры. Но это не делает их быстрыми.
К тому же, быстрым код становится после оптимизации. А зачастую оптимизация приводит к усложнению кода, ввиду специальной обработки частных случаев, использования некрасивого низкоуровнего кода, и прочих штук, усложняющих код.
К тому же, быстрым код становится после оптимизации. А зачастую оптимизация приводит к усложнению кода, ввиду специальной обработки частных случаев, использования некрасивого низкоуровнего кода, и прочих штук, усложняющих код.
раскрыть ветку (2)
Ну я не говорил абсолютную истину, а всего лишь утверждал, что если код проще - то это не значит, что он хуже. Насчет неочевидностей в твоем примере, конечно согласен.