Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, SEO та всього пов'язаного з інтернетом та комп'ютерами.
Будемо вдячні, якщо ви поділитись посиланням на Replace.org.ua на інших ресурсах.
Для того щоб створювати теми та надсилати повідомлення вам потрібно Зареєструватись.
Український форум програмістів → C#, .NET → Чи впливає кількість вікон в проекті Visual studio на споживання RAM?
Сторінки 1
Для відправлення відповіді ви повинні увійти або зареєструватися
.NET, WPF. Планується багацько вікон з унікальним вмістом які будуть створюватися (m = new Window500) у відповідь на дії користувача. Як це вплине на споживання оперативки? Воно все завантажиться в оперативку і всі сотні класів Window будуть просто займати місце?
ґкщо в тебе ще SSD вінчестер, то більший факт що буде в оперативній пам'яті
У чому проблема перевірити?
Після виконання "m = new Window500" цей об'єкт буде висіти в пам'яті. Щоб збирач сміття зміг його вчасно видалити, отут радять ставити правильний Parent: https://stackoverflow.com/questions/14411154/a-wpf-window-doesnt-release-the-memory-after-closed Але це якщо у вас дуже проста юайка, без сторонніх компонентів. Бо сторонні компоненти запросто можуть тримати посилання на непотрібне вікно десь в своєму коді. Для виправлення таких проблем існують профілювальники, наприклад dotMemory або .Net Memory Profiler. У майкрософта також були якісь тулзи для цього.
Хоча усе це не гарантує нормального результату, якщо ваша програма має працювати 24/7. В таких випадках краще розділяти код, який має працювати постійно і юайку на окремі процеси. Тобто процес, який працює постійно, створює лише іконку в треї і просте меню, а коли треба показати решту юайки, то він запускає інший exe-файл.
На жаль, проблема з якою ви зіткнулися - це слабке місце усіх мов зі збирачем сміття. Виключенням є лише Swift, бо там збирач сміття не на основі алгоритму обходу дерева, а на основі підрахунку посилань. Відповідно у нього зовсім інші сильні та слабкі сторони.
Виявилося що це погана задумка. 1420 фаликів з віконцями і на додачу картинок на пару гігабайтів. При компіляції Visual studio випадає через нестачу оперативки а результуючий екзешник в конфігурації debug займає 612 Мб. В оперативку воно все не завантажується а лише ті вікна які створюються. Вдалося провести компіляцію видаливши всі файли в папках Release і Debug. Побачу що буде далі.
1420 фаликів з віконцями і на додачу картинок на пару гігабайтів. При компіляції Visual studio випадає через нестачу оперативки а результуючий екзешник в конфігурації debug займає 612 Мб.
Зупинися, подумай шо ти робиш і для чого. Release/*.exe мав зайняти Kb, не Mb. Повикидай все шо не є наслідком потреби. Всі зовнішні ресурси мають залишитися зовнішніми, не пхай їх в *.exe.
І ше взагалі не факт чи треба тобі WPF для такої задачі.
Тримати картинки прямо в формах - це погана ідея. Якщо уже дуже треба зробити одним exe-файлом, то можна спробувати додати їх у ресурси. Це мало би допомогти компілятору впоратись. Але краще закинути усі картинки у звичайний zip-архів, і розповсюджувати його разом з програмою.
.NET, WPF. Планується багацько вікон з унікальним вмістом які будуть створюватися (m = new Window500) у відповідь на дії користувача. Як це вплине на споживання оперативки? Воно все завантажиться в оперативку і всі сотні класів Window будуть просто займати місце?
Однозначно вплине зростанням споживання пам'яті. Але чесно окрім пам'яті хвилювався би за процесор, бо перемикань контексту схоже буде пісець як дофіга.
Сторінки 1
Для відправлення відповіді ви повинні увійти або зареєструватися
