Доброго времени суток всем! Появилась такая проблемма. В общем написал я маленькую прожку с таймером. Таймер при старте принудительно отключается. Пр старте никаких операций не выполняется. Прога на винте занимает ок. 50 кБайт. Но при старте в оперативе занимает 10 метров. Компилил под студией и под #Develop - результат один и тот же. Подскажите пожалуйста может надо что-то в студии настроить? Или это из-за программирования на .net? Или в чем может быть причина? Буду очень благодарен.

Есть некоторая плата за автоматическую сборку мусора, защищенность AppDomain-ов и адаптацию под конкретный процессор с помощью JIT-компиляции. Эта плата включает в себя небольшое обжорство памяти при маленьких программах и в некоторых случаях небольшой потерей производительности (только в некоторых. В иных может оказатся быстрее)

Если будет написано что-то большое, то этих лишних метров памяти практически не будет заметно - CLR при запуске сборки сразу резервирует под данные приличное количество места + разные таблицы, свободное место для JIT и AppDomainы та конексты. В таких случаях очень серйозная програма от програмы с двумя строчками могут отличатся в памяти на 1-2 мегабайта  

Если же нужна програма которая весит килобайты в памяти то .Net - плохой выбор)

Добавлено через 44 секунды

А эт неважно - компилятор то все равно один и тот же

А в самой студии нельзя поограничивать скажем адаптацию под проц? Вроде там такое где-то есть... Производительность не падает (индекс таймера 100 и каждый разб проверка - и нормально), но конечно с оперативкой - это засада :-( Получается при написании под  .net приходится жертвовать памятью. А принудительно все таки нелбзя отключить все эти алгоритмы? Я просто пока новичек, в принципе слышал и о сборке мусора и о прочих вещах, но все-таки....

 Эти алгоритмы и составляют .net технологию. Без них это не .Net просто )

 Можно, только оно совсем не для того) И нужного ефекта не даст


Имел ввиду сравнение managed или unmanaged кода


если ты будешь писать каждое свое приложение по 1 строчке кода - то да, ты будешь жертвовать памятью. Если же приложение довольно большое, то памяти будет жрать самое оно.

Что ни говорите, в M$ умные люди сидят - и разработку оптимизировали под "среднее приложение". При разработке каких-то очень не стандартных приложений (как приложения с 1 строчкой кода) .нет не совсем удачен. Взять даже GC который прекрасно справляется с среднестатестичискими обьемами данных, но загинается очень быстро на некоторых тестах (быстрее чем другие коллекторы)

Можно подробнее?

Не понял, но, думаю, это проблему не решит  Ладно, спасибо за объяснение. Кстати ведь для прог под .net этот самый .net должен же быть на компе? Если это так - то это объясняет "склонность" шарпа к немаленьким приложениям - вряд ли пользователь будет выкачивать для малюсенькой утилиты весь .net

Да, но по-идее у каждого пользователя должен уже быть установлен .net (Имею ввиду такая идея M$)


Видел где-то тест, при котором GC показывает себя намного и намного хуже чем аналогичные сборщики мусора (кажись пару десятков минут, когда другие - пару секунд). Тем не менее тест был специально на то чтобы показать работу GC - тест делает такие условие, которые просто на практике невозможны )
поищу - кину сцылку

Это сообщение отредактировал(а) archeg - 5.9.2007, 18:50

Раз для теста делали - видимо на практике возможно. Давно как-то писал программу довольно хитроумную, так там видимо GC как раз захлёбывался. Суть была в том, что примерно 50 раз в секунду происходили некие преобразования с небольшими объёмами данных (в нескольких потоках) и выводилось всё это на экран (с такой же частотой). С точки зрения кода всё было гениально и просто, но приложение работало просто по какому-то чудовищному фактору везения: захочет, выкинет ObjectNotFound эксепшн через 5 секунд, захочет - через 10... Но чтобы всё было стабильно - никогда. Мистика...   

Похожая фигня была у меня с потоками таймера и messagebox. Этот самый бокс выводился то 3. то 5. то 0 раз... Знаете, в этом топике сплошной негатив в адрес .net... Главное, чтоб позитив был   

Может быть где-то lock не стоял? )
Если где-то неправильно заблокировать что-то в многопоточных приложениях, то очень часто появляются такие баги - что можно месяц над ним бится   Особенно если использовать lock(this)


Почему же негатив? ) Я считаю .net - самая развитая и во всех отношениях лучшая платформа. (Думаю java тоже будет уступать .net хотя бы из-за шикарной поддержки. Но это уже субьективное мнение и оно еще ничего не значит).

Просто для того чтобы позитивно работать на самой позитивной платформе, нужно знать ее негативные стороны  

Великолепно сказано!