Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > .NET Frameworks (точка нет фреймворки) > C# (си шарп)
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 10.02.2017, 18:13   #21
Пепел Феникса
Старожил
 
Аватар для Пепел Феникса
 
Регистрация: 28.01.2009
Сообщений: 21,000
По умолчанию

Цитата:
Сообщение от OmegaBerkut Посмотреть сообщение
И скоростью реагирования сборщика.
максимум изменится время когда объект станет свободным.
но впрочем я об этом писал.

про жесткий диск уже сказали.
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
Программа делает то что написал программист, а не то что он хотел.
Функции/утилиты ждут в параметрах то что им надо, а не то что вы хотите.
Пепел Феникса вне форума Ответить с цитированием
Старый 10.02.2017, 18:22   #22
OmegaBerkut
Спокойный псих
Участник клуба
 
Аватар для OmegaBerkut
 
Регистрация: 19.03.2013
Сообщений: 1,538
По умолчанию

Цитата:
Сообщение от Alex11223 Посмотреть сообщение
Дык чтоб не вешался UI надо не саму работу замедлять, а только с выводом что-то делать.
Саму работу замедляю не для того, что бы не вешался UI. Повторяю:
1 - поток для того, что бы не вешался UI
2 - замедление для того, что бы процесс не нагружал ЦП; в данном случае скорость выполнения не столь важна, важнее что бы программа не упала.

Цитата:
Сообщение от Alex11223 Посмотреть сообщение
Может и вообще не надо все выводить.
Цель-то кстати какая? Зачем нужен этот список всех файлов?
Поставил себе задачку для выполнения, как студент.
1) получить древовидный список всех под/каталогов и файлов, начиная с указанного;
2) по полученному файлу построить TreeView;
3) гвоздь программы - сделать это собственно доступными и сооружёнными средствами аля костыли и велосипеды; просто что бы убедиться , что могу.

Первый пункт уже выполнил.

На счёт танков и диска - погорячился с выражениями ... Действительно, про запись на хард забыл.
Подпись ? Не, не слышал ...
OmegaBerkut вне форума Ответить с цитированием
Старый 10.02.2017, 18:28   #23
Alex11223
Старожил
 
Аватар для Alex11223
 
Регистрация: 12.01.2011
Сообщений: 19,500
По умолчанию

Посмотрите на любую программу со списком всех файлов (проводник, тотал командер, дропбокс, ...). Они ж не грузят сразу весь список со всего диска, а подгружают по необходимости (при переходе).

Весь список грузят разве что программы для бэкапа во время бэкапа.
Ушел с форума, https://www.programmersforum.rocks, alex.pantec@gmail.com, https://github.com/AlexP11223
ЛС отключены Аларом.
Alex11223 вне форума Ответить с цитированием
Старый 10.02.2017, 18:33   #24
OmegaBerkut
Спокойный псих
Участник клуба
 
Аватар для OmegaBerkut
 
Регистрация: 19.03.2013
Сообщений: 1,538
По умолчанию

Цитата:
Сообщение от Пепел Феникса Посмотреть сообщение
максимум изменится время когда объект станет свободным
Из моего опыта: цикл с вызовом GC.Collect() работает в ~15 раз дольше ...
Если коллект не вызывать, а просто занулить ссылку, которая находится в локальной области видимости - сборщик сам очистит память; и освобождение произойдёт быстрее, нежели когда я покину область видимости объекта.
Для глобальных объектов после зануления ссылки можно вызывать GC.Colect(), но ни в коем случае не в цикле. Как я и поступаю при ежеминутном сбросе данных в файл.
Подпись ? Не, не слышал ...
OmegaBerkut вне форума Ответить с цитированием
Старый 11.02.2017, 00:27   #25
OmegaBerkut
Спокойный псих
Участник клуба
 
Аватар для OmegaBerkut
 
Регистрация: 19.03.2013
Сообщений: 1,538
По умолчанию

Вот что действительно правильнее и логичнее - скидывать данные в файл не дополнительным потоком раз в минуту, а при каждом переходе обратно на уровень выше по каталогам ... Да и надёжнее так.
upd: и как то так интересно получилось ...
Цитата:
Сообщение от OmegaBerkut Посмотреть сообщение
Для глобальных объектов после зануления ссылки можно вызывать GC.Colect(), но ни в коем случае не в цикле. Как я и поступаю при ежеминутном сбросе данных в файл
Я когда прописал это - не проверял на сколько лучше работает программа, потому что был уверен, что лучше ...
При тестировании "нового метода" сброса данных я наблюдал за загрузкой ЦП, и случайно обратил внимание на использование памяти ... Не выросло выше 12 мб - то увеличивалось, то уменьшалось; оно и понятно - постоянно гуляет по стеку вызовов. До того как я прописал GC.Collect() - использование памяти прыгало рывками от 10 до 15 метров, а сейчас всё плавненько ...
На скорость получения конечных данных оказано положительное влияние - выросло до ~1 мб в минуту (было ~0.5); откуда растут ноги прироста - мне не понятно ... Может из-за того, что пропал второй поток, как и синхронизация с ним.
Подпись ? Не, не слышал ...

Последний раз редактировалось OmegaBerkut; 11.02.2017 в 00:42.
OmegaBerkut вне форума Ответить с цитированием
Старый 11.02.2017, 01:14   #26
Пепел Феникса
Старожил
 
Аватар для Пепел Феникса
 
Регистрация: 28.01.2009
Сообщений: 21,000
По умолчанию

Цитата:
Сообщение от OmegaBerkut Посмотреть сообщение
и освобождение произойдёт быстрее, нежели когда я покину область видимости объекта.
кэп, я разве об этом не говорил?
значит у вас переменная живет дольше необходимого.
но суть от этого не меняется. это мелочи.


Цитата:
Сообщение от OmegaBerkut Посмотреть сообщение
До того как я прописал GC.Collect() - использование памяти прыгало рывками от 10 до 15 метров, а сейчас всё плавненько ...
естественно, почитайте что такое принудительная сборка мусора ВСЕХ ПОКОЛЕНИЙ.
против частой сборки нулевого поколения(едва созданные объекты).
полная сборка соберет больше, что очевидно.

не стоит работать по принципу, "слышал звон, не знаю где он".
все это документировано и расписано.

Цитата:
Сообщение от OmegaBerkut Посмотреть сообщение
Вот что действительно правильнее и логичнее - скидывать данные в файл не дополнительным потоком раз в минуту, а при каждом переходе обратно на уровень выше по каталогам ... Да и надёжнее так.
для файлового менеджера в принципе не надо кэшировать эти данные, это работа ФС.
при изменении в папке легко получите упущенный файл.
Цитата:
2) по полученному файлу построить TreeView;
3) гвоздь программы - сделать это собственно доступными и сооружёнными средствами аля костыли и велосипеды; просто что бы убедиться , что могу.
ленивые вычисления, максимум вам нужно лишь проверять, есть ли в папке еще данные или она пуста(но для этого не нужен полный список файлов/папок).
загружено только то что видимо, остальное не храним.
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
Программа делает то что написал программист, а не то что он хотел.
Функции/утилиты ждут в параметрах то что им надо, а не то что вы хотите.
Пепел Феникса вне форума Ответить с цитированием
Старый 11.02.2017, 01:42   #27
OmegaBerkut
Спокойный псих
Участник клуба
 
Аватар для OmegaBerkut
 
Регистрация: 19.03.2013
Сообщений: 1,538
По умолчанию

Цитата:
Сообщение от Пепел Феникса Посмотреть сообщение
но суть от этого не меняется. это мелочи.
Это не мелочи, когда речь идёт о тяжеловесной обработке большого массива тех же строк ...
Допустим, у меня в массиве 500 строк, которые я обрабатываю циклом; в конце тела цикла я зануляю текущий элемент массива по индексу, так как более мне этот элемент не потребуется; и продолжаю работать со следующими элементами; рано или поздно сборщик мусора освободит ту память, на которую когда то ссылался ранее занулённый элемент, и это произойдёт в процессе работы с массивом. В итоге - на выходе из цикла у меня уже будет свободна вся та память, которая использовалась всеми ссылками в массиве (до входа в цикл).
БЕЗ зануления на выходе из цикла память будет зарезервирована, так как все ссылки ещё живы, и находятся в активной области видимости.
А ведь в процессе обработки отдельно взятого элемента будет выделяться дополнительная память по необходимости алгоритма обработки.
Цитата:
Сообщение от Пепел Феникса Посмотреть сообщение
сборка мусора ВСЕХ ПОКОЛЕНИЙ
Я читал об этом, и имею общее представление. Чего мне пока более чем достаточно.
Цитата:
Сообщение от Пепел Феникса Посмотреть сообщение
при изменении в папке
В том то и дело, что я "делаю полный снимок" (кэширую), а доступ к ФС может быть не всегда, и не везде.
Подпись ? Не, не слышал ...

Последний раз редактировалось OmegaBerkut; 11.02.2017 в 02:07.
OmegaBerkut вне форума Ответить с цитированием
Старый 11.02.2017, 02:16   #28
Пепел Феникса
Старожил
 
Аватар для Пепел Феникса
 
Регистрация: 28.01.2009
Сообщений: 21,000
По умолчанию

Цитата:
Сообщение от OmegaBerkut Посмотреть сообщение
Допустим, у меня в массиве 500 строк, которые я обрабатываю циклом; в конце тела цикла я зануляю текущий элемент массива по индексу, так как более мне этот элемент не потребуется; и продолжаю работать со следующими элементами; рано или поздно сборщик мусора освободит ту память, на которую когда то ссылался ранее занулённый элемент, и это произойдёт в процессе работы с массивом. В итоге - на выходе из цикла у меня уже будет свободна вся та память, которая использовалась всеми ссылками в массиве (до входа в цикл).
БЕЗ зануления на выходе из цикла память будет зарезервирована, так как все ссылки ещё живы, и находятся в активной области видимости.
А ведь в процессе обработки отдельно взятого элемента будет выделяться дополнительная память по необходимости алгоритма обработки.
Цитата:
если вам так важна память этих строк, то не надо было грузить их все в память, в итоге вы не понизили пик памяти, а уменьшили его длину, что в 99% случаев обычно не так важно.(если конечно не пихать 999 вещей на один комп и все заставлять работать одновременно)
на первой итерации у вас потребление памяти не уменьшилось, итого смысла нет практического нет, если система перенесет пик, дальше уже не так важно.(точнее длина пика важна если нет возможности снизить пик, но это не наш случай)
я уж промолчу про такие вещи как GC Pressure и Heap defragmentation.
итого вместо нормальной поточной обработки без лишних ресурсов и минимумом оверхеда(она при этом еще и довольно универсальна будет, за счет IEnumerable), вы делаете костыль что будет медленнее.

файл в тысячу строк тоже будете целиком грузить? а в миллион?

преждевременная оптимизация зло.

Цитата:
Сообщение от OmegaBerkut Посмотреть сообщение
Я читал об этом, и имею общее представление. Чего мне пока более чем достаточно.
вы тут уже показали что не знаете этого.
Цитата:
В том то и дело. что я "делаю полный снимок" (кэширую), а доступ к ФС может быть не всегда, и не везде.
как я говорил полный список не имеет смысла, задумайте почему программы удаленного доступа не делают полный снимок ФС. да потому что половина этих папок пользователю не будет нужна, зачем грузить лишнее?
как я сказал, преждевременная оптимизация зло, вы в итоге гоняясь за мегабайтами(при парой из 15!, а не сотня из Гб) пропускаете логические ошибки.
снимок ФС нужен для разных каталогизаторов, систем контроля версий.
но отнюдь не для файлового менагера, всему свое место.

вас так послушать так 99% ентерпрайза падать должно
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
Программа делает то что написал программист, а не то что он хотел.
Функции/утилиты ждут в параметрах то что им надо, а не то что вы хотите.

Последний раз редактировалось Пепел Феникса; 11.02.2017 в 02:18.
Пепел Феникса вне форума Ответить с цитированием
Старый 11.02.2017, 03:37   #29
OmegaBerkut
Спокойный псих
Участник клуба
 
Аватар для OmegaBerkut
 
Регистрация: 19.03.2013
Сообщений: 1,538
По умолчанию

Цитата:
Сообщение от Пепел Феникса Посмотреть сообщение
но отнюдь не для файлового менагера
Кто сказал, что я пишу файловый манагер ? Вдруг я пишу сканер для того, что бы посмотреть, что есть у другого человека на компьютере ? А файл результатов сканирования отправлять на почту ... Этим можно объяснить абсолютно все мои мотивы: полный кэш указываемой папки, построение TreeView, минимум нагрузки на ЦП и ОЗУ ...
Цитата:
Сообщение от Пепел Феникса Посмотреть сообщение
вы в итоге гоняясь за мегабайтами(при парой из 15!
Опять же - это чисто для себя.
Цитата:
Сообщение от Пепел Феникса Посмотреть сообщение
файл в тысячу строк тоже будете целиком грузить? а в миллион?
Ну да, у меня например после сканирования диска D:\ на выходе примерно 250 000 строк в файле - 11,5 мегабайт юникода.
Подпись ? Не, не слышал ...

Последний раз редактировалось OmegaBerkut; 11.02.2017 в 03:56.
OmegaBerkut вне форума Ответить с цитированием
Старый 11.02.2017, 13:41   #30
Пепел Феникса
Старожил
 
Аватар для Пепел Феникса
 
Регистрация: 28.01.2009
Сообщений: 21,000
По умолчанию

я вам уже сказал прочитать Сагу об X,Y,Z.

если вы скажете что нужно в итоге, тогда можно будет дать советы.

Цитата:
Сообщение от OmegaBerkut Посмотреть сообщение
минимум нагрузки на ЦП и ОЗУ ...
понижение нагрузки на ЦП достигается понижением скорости работы приложения(при условии что у вас нет глупостей в коде)
ОЗУ лечится поточной обработкой, без загрузки всего разом в память.
гораздо лучше держать память на уровне 15мб, чем позволять скачки от 10 до 20, меньше нагрузка на менеджер памяти системы.(ну и уплотнение кучи, операция не бесплатная)
и да кстати, диспетчер задач не показывает реальную картину потребления памяти внутри приложения, часть страниц обычно зарезервирована для расширения кучи, возвращаются системе позже.
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
Программа делает то что написал программист, а не то что он хотел.
Функции/утилиты ждут в параметрах то что им надо, а не то что вы хотите.
Пепел Феникса вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
узнать есть ли в массиве одинаковые числа lanabanana Общие вопросы Delphi 12 23.02.2016 15:42
С какой стороны функция LORDIF Общие вопросы C/C++ 1 28.05.2012 22:38
ListView как узнать есть ли строки? Кольша Мультимедиа в Delphi 4 27.08.2011 14:17
Стороны света ≈ стороны монитора Alex Cones Свободное общение 21 26.08.2010 17:15