Ви не увійшли. Будь ласка, увійдіть або зареєструйтесь.
Ласкаво просимо вас на україномовний форум з програмування, веб-дизайну, 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. ви скоріше за все плутаєте опис вашего вікна/class (технічно вікно і є class), зі створенням екземпляру цього вікна. Вам вище вже про це писали, але якщо коротко: можна оголосити 100500 вікон, але створювати в моменті лише одне і це займатиме мінімум місця в RAM. Можна оголосити один тип вікна, але створити 100500 копій, і це виїсть всю оперативну пам'ять.
2. Закриття вікна повино супроводжуватись знищенням посилання на об'єкт наприклад шляхом currentWindow = null. Лише в цьому разі GC зачисте вікно, при умові що на його властивости/поля/методи не посилаються інші об'єкти. Тут питання скоріше в тому наскільки гарно ви вмієте будувати архітектуру застосунку, щоб уникати жорстких зв'язків між класами та створюємими об'єктами.
3. загалом WPF це технологія котра передбачає використання патерну MVVM. Як на мене "багато вікон" загалом погана ідея, зручніше мати одне вікно і купу UserControl. Чомусь новачки дуже рідко використовують UserControl, хоча с точки зору розробки це набагато краще.
4. Студія пережує хоч 100500 вікон. Хоча така кількість вікон викликає певні питання: там дійнос неможливо систематизувати відображаєму інформацію, щоб мати кілька типів вікон, і просто в рантаймі визначати що показувати, а що ні?
Тримати картинки прямо в формах - це погана ідея
Абсолютно нормальна ідея для невеликих зображень, що завжди треба відображати, наприклад логотип застосунку. Інше питання що там за зображення у автора теми.
якщо в тебе ще SSD вінчестер, то більший факт що буде в оперативній пам'яті
Але чесно окрім пам'яті хвилювався би за процесор, бо перемикань контексту схоже буде пісець як дофіга.
Вперше чую про таке. Можливо я не правий, але наскільки знаю це працює не так, і той факт що програма на SSD і буде створюватись багато вікон в процесі роботи не повинно створювати проблем.
Сторінки 1
Для відправлення відповіді ви повинні увійти або зареєструватися
