JAVA → Объекты Java
Под впечатлениями от habrahabr.ru/blogs/java/134102/.
Недавно мне приходилось немного поковыряться внутри JVM. Довольно интересный опыт. Текст в вышеупомянутом топике не совсем сходится с моим опытом, но я не считаю себя обладателем абсолютной истины. Ниже я поделюсь с читателями небольшой частью моих экспериментов, которые касаются непосредственно объектов Java.
Недавно мне приходилось немного поковыряться внутри JVM. Довольно интересный опыт. Текст в вышеупомянутом топике не совсем сходится с моим опытом, но я не считаю себя обладателем абсолютной истины. Ниже я поделюсь с читателями небольшой частью моих экспериментов, которые касаются непосредственно объектов Java.
Erlang/OTP → Архитектура памяти: Erlang против Java
Я прочитал очень-очень интересную статью «Стратегии управления памятью для Erlang VM». Она была написана в качестве диссертации Джеспером Вильхельмсоном. Я подумал, что было бы неплохо обсудить различия между управлением памятью в Erlang и Java VM от Oracle.
Python → Профилирование python приложений
Краткая заметка с линками и примерами о профайлинге:
- производительности: hotshot или python profile/cProfile + визуализатор логов kcachegrind (есть порт под windows, аналог WinCacheGrind)
- использование памяти: dowser с web-интерфейсом
Высокая производительность → Highload на дешевом хостинге: хэш-таблица в MySQL
Высоконагруженный проект (web-сайт) — не обязательно популярная социальная сеть, видеохостинг или MMORPG. Простейший способ резко повысить требования сайта к железу — перенести хранение сессий в БД. В этой статье мы рассмотрим способ хранить данные в БД, и при этом не жертвовать производительностью. Пожертвовав небольшим объемом ОЗУ можно прилично сэкономить процессорное время. Мы говорим о стиуации, когда недоступны memcached и другие специальные средства кэширования.
Apple → Nano цены
Цены на плеер Nano от Apple неуклонно снижаются, спасибо прогрессу и падающей цене на память.
2005 (2GB)
Розничная цена $199
Цветной дисплей, нет жесткого диска
Цена компонентов $90.18
Память $54 (Поставщик Samsung)
Экран $9
2005 (2GB)
Розничная цена $199
Цветной дисплей, нет жесткого диска
Цена компонентов $90.18
Память $54 (Поставщик Samsung)
Экран $9
Разработка → Галерея эффектов кэшей процессоров
Почти все разработчики знают, что кэш процессора — это такая маленькая, но быстрая память, в которой хранятся данные из недавно посещённых областей памяти — определение краткое и довольно точное. Тем не менее, знание «скучных» подробностей относительно механизмов работы кэша необходимо для понимания факторов влияющих на производительность кода.В этой статье мы рассмотрим ряд примеров иллюстрирующих различные особенности работы кэшей и их влияние на производительность. Примеры будут на C#, выбор языка и платформы не так сильно влияет на оценку производительности и конечные выводы. Естественно, в разумных пределах, если вы выберите язык, в котором чтение значения из массива равносильно обращению к хеш-таблице, никаких результатов пригодных к интерпретации вы не получите. Курсивом идут примечания переводчика.
Железо → Разгон памяти DDR3 3000МГц+
Добрый день.
Простая истина гласит, гнать нужно то что гонится. Успешному разгону кроме центральных процессоров, неплохо поддается системная память. Но не все йогурты одинаково полезны, а точнее не все микрочипы хорошо гонятся относительно своей номинальной частоты.
.NET → Память: LOH и Chunked Lists
Управляемая память в .Net поделена на стек и несколько хипов. Самые важные из хипов – это обычная (эфемерная) куча и LOH. Эфемерная куча – это то место, где живут все обычные объекты. LOH – это то место где живут большие (больше 85000 байт) объекты.
LOH обладает некоторыми особенностями:
Из этих двух особенностей LOH происходят два важных следствия, про которые часто забывают:
Если вспомнить, что LOH аллоцируется кусками по 16Mb, то все происходящее покажется еще более разрушительными. С первым следствием можно бороться аккуратно переиспользуя объекты. Со вторым — не используя большие объекты. Получается как-то не очень, особенно если с большими коллекциями работать все-таки хочется. Посмотрим, что как можно решить эту проблему.
LOH обладает некоторыми особенностями:
- Объекты в LOH никогда не перемещаются
- LOH только растет и никогда не уменьшается (т.е. если объект собран сборщиком мусора, размер LOH все равно остается неизменным)
- Хип LOH освобождается только тогда, когда LOH полностью пуст
Из этих двух особенностей LOH происходят два важных следствия, про которые часто забывают:
- Память в LOH может оказаться фрагментированной. Т.е. происходит то, с чем так боролись в unmanaged мире: в какой-то момент у вас может быть 10Mb свободной памяти, но вы не сможете выделить память под объект размером 1Mb
- Если вы однажды выделили память под большой объект, а потом используете только маленькие, то вы фактически лишаете себя большого куска памяти. При чем, если у вас в LOH был список или хэш-таблица размером N, а вы добавили в него один элемент, то список реаллоцируется и растет в два раза, сответственно размер LOH составит как минимум 3*N (N – исходные данные, 2N – копия данных и резерв под новый размер). Следующий рост потребует в LOH непрерывный кусок памяти размером в 4*N, а так как такого куска в LOH у нас нет (есть только N), его придется позаимствовать из адресного пространства процесса. В итоге размер LOH вырастет до 7*N, и так далее.
Если вспомнить, что LOH аллоцируется кусками по 16Mb, то все происходящее покажется еще более разрушительными. С первым следствием можно бороться аккуратно переиспользуя объекты. Со вторым — не используя большие объекты. Получается как-то не очень, особенно если с большими коллекциями работать все-таки хочется. Посмотрим, что как можно решить эту проблему.
Google Chrome → Чистка оперативки
Мы знаем, что Google Chrome — самый быстрый и один из наименее требовательных браузеров. Но если вы все-же испытываете недостаток в оперативной памяти, причиной которому стал Chrome, то достаточно добавить --purge-memory-button в командную строку запуска. И будет вам счастье.
Узнал здесь