Здравствуйте, Klatu, Вы писали:
K>2005 год, 1-ядерный проц, 1 гиг оперативки, WinXP, VS2005. Все летает со свистом. K>2011 год, 4-ядерный проц, 4 гига оперативки, Win7, VS2010. Все тормозит. K>Печаль
2011 год, Core i3, 3.2 ГГц, 4 гига оперативки, Win7 SP1, VS 2008 — все летает
Здравствуйте, CreatorCray, Вы писали:
B>> В начале 90-х в журнале “Монитор” или “Мир ПК” или в … — приводился пример – B>> кусок кода с классами и кусок кода без выпендрежа – без классов. Разница во времени исполнения –в 11 раз. CC>Что то мне кажется что там был явный говнокод с классами. Или компилятор полное говно. CC>Сами по себе классы не дают тормозов.
20 лет назад все было совершенно иначе и компилер просто не умел оптимизировать. Чуть не единственная оптимизация это были инлайны.
Watcom C++ генерил отличнй код хоть с классами, хоть без оных.
Здравствуйте, Klatu, Вы писали:
CC>>Что то мне кажется что там был явный говнокод с классами. Или компилятор полное говно. CC>>Сами по себе классы не дают тормозов.
K>Скорее всего, там была какая-нибудь эльфийская реализация в духе "вызов метода — посылка сообщения"
Скачай Borland C++ 3.10 и посмотри какой он код генерит — мало не покажется В статье в журнале скорее всего именно борландовский компилер и использовался.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Ytz, Вы писали:
Ytz>>Я в 2004 году, работая дизайнером, делал в Photoshop макеты рекламных щитов 6 м * 3 м при разрешении 150 dpi на компе с 1 Гб оперативной памяти. Тормозило, да, но работать было можно. С какого же перепугу сейчас стало мало 4? Почему для Fedora 14 моего старого ноута с 2 Гб вполне достаточно?
M>Когда я был молод у меня было 8 мегабайт оперативки и я вполне был доволен и комфортно работал , с какого перепугу это теперь мало ?
когда я был молод у меня было 48 _килобайт_ оперативки и это было много, потому как это этого было то ли 32 Кб, то ли 16 Кб.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Klatu, Вы писали:
K>2005 год, 1-ядерный проц, 1 гиг оперативки, WinXP, VS2005. Все летает со свистом. K>2011 год, 4-ядерный проц, 4 гига оперативки, Win7, VS2010. Все тормозит. K>Печаль
если бы только оперативка... когда-то было фидо и голый дед. и в сообщениях нормальная подсветка и никаких проблем с квотингом. а сейчас в аутлуке задолбаешься. хочешь убрать горизонтальную линию, а не можешь. шрифты меняются странным и причудливым образом. больше трахаешься, чем работаешь. и все реже видишь, чтобы кто-нибудь квотил письма и потому на письма уже отвечают без цитирования и чтобы вникнуть в суть нужно читать всю нитку (благо она обычно внизу письма), и никакой оперативой тормоза редактирования почты неустранимы. и не только почты.
зы. сейчас распаковал на NTFS полмиллиона файлов в один каталог. вынь не сдохла, но фар загнулся. работать с каталогом можно только из командой строки, да и то мееееедленно. ни одна оболочка не позволяет ничего делать. а что такое полмиллиона файлов при современных мощностях? они целиком вместе со всем своим содержимым занимают меньше 8 Гб. их кэшировать от не фиг делать. это же надо настолько тупо все организовать, чтобы отъдать чуть меньше двух гигов только для отображения их имен и тупо дохнуть. кстати, far прежде чем сдохнуть еще и лажает. имена файлов -- md5. far доходит только до d1* и грит, что вуаля, типа это все, что есть -- нате. куда делись имена d2* — ff* -- вот это я бы хотел спросить. да, у меня 32 бита, но... почему-то хрюндекс в тех же условиях обрабатывает эти файлы питоновским скриптом быстрее, чем хрюша на сишной программе, вызваемой из пакетного файла из цикла for с именами файлов. цикл тормозит аццки. XXI век блин... я уже молчу о том, что винда не позволяет удалять эти файлы и тут можно только форматировать том. другого способа нет. в mft они останутся и после удаления.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, Klatu, Вы писали:
K>Здравствуйте, Sinix, Вы писали:
S>>Так поставьте xp и 2005ю.
K>Жить в прошлом — не выход. Новые фичи все-таки нужны, хотя бы заказчику Видимо, придется докупать еще 4 гига оперативки и SSD. K>Но это все равно звиздец. Что-то основательно прогнило в датском королевстве.
Поражает, до чего люди жадные бывают на то чтобы потратить жалкие гроши на инструмент, с помощью которого зарабатывают на хлеб, а потом ноют. Сколько Вы получаете в месяц? Неужели проблема из этих денег действительно потратить 50 баксов на дополнительных 4 гига оперативки? Ведь они действительно нужны, и это далеко не излишество, хотя бы для того чтобы запускать параллельно несколько виртуальных машин (как это делаю я), одновременно держа открытыми несколько копий Visual Studio, возможно еще Photoshop и т.д.
Здравствуйте, vl690001x, Вы писали:
V>Поражает, до чего люди жадные бывают на то чтобы потратить жалкие гроши на инструмент, с помощью которого зарабатывают на хлеб, а потом ноют. Сколько Вы получаете в месяц? Неужели проблема из этих денег действительно потратить 50 баксов на дополнительных 4 гига оперативки? Ведь они действительно нужны, и это далеко не излишество, хотя бы для того чтобы запускать параллельно несколько виртуальных машин (как это делаю я), одновременно держа открытыми несколько копий Visual Studio, возможно еще Photoshop и т.д.
Это не проблема. Просто меня раздражает безумно неэффективное использование ресурсов. С теперешними мощностями можно было бы радикально улучшить user experience, а вместо этого — всё тот же старый говнософт, только с новыми красивыми кнопочками и в три раза тормознее старого.
Здравствуйте, Klatu, Вы писали:
K>2005 год, 1-ядерный проц, 1 гиг оперативки, WinXP, VS2005. Все летает со свистом. K>2011 год, 4-ядерный проц, 4 гига оперативки, Win7, VS2010. Все тормозит. K>Печаль
Да, достает немного
На лептопе проц i7Q720, 8 гиг оперативки, 2 винта — системный OCZ Vertex3 240 Gb Max IOPS
VS2005 летает, VS2010 тормозит. Еще каким то чудным образом служба для оптимизации отображения шрифтов на WPF периодическо отъедает под 100% одного из ядер.
Возможно, причины тормозов это переезд VS на WPF?
Здравствуйте, de Niro, Вы писали:
DN>Здравствуйте, Banned by IT, Вы писали:
CC>>>>2011 год, 2-ядерный проц, 2 гига оперативки, Win2003 x86, MSVC 2008 + ICC 12. Все летает со свистом. B>>>30 сантиметров BBI>>В диаметре!!!
DN>В холодной воде!
Не напряженный
N_>Дело в том, что большую часть кода и не надо оптимизировать. Обычно 1% кода сжирает 99% вычислительный ресурсов при работе приложения. Вот этот 1% в нативном коде и оптимизирую блягодаря полноценному доступу к любым низкоуровневым средствам, что сложно будет сделать в java или .net.
Увы, но я всё чаще сталкиваюсь с тем, что ресурсы поедаются тонким ровным слоем. В текущем проекте все хотспоты и устранили очень быстро, но уперлись в потере производительности на многослойных конструкциях. Собственно выше описаная ситуация.
Здравствуйте, -VaS-, Вы писали:
I>>2011 год, 2ядерный ноутбук которому уже три года, 3 гига оперативы, Win7-64, VS2010 + Решарпер, Все летает. I>>Что я не так делаю ?
VS>Размер солюшена?
Здравствуйте, мыщъх, Вы писали:
М>... почему-то хрюндекс в тех же условиях обрабатывает эти файлы питоновским скриптом быстрее, чем хрюша на сишной программе, вызваемой из пакетного файла из цикла for с именами файлов. цикл тормозит аццки. XXI век блин... я уже молчу о том, что винда не позволяет удалять эти файлы и тут можно только форматировать том. другого способа нет. в mft они останутся и после удаления.
В Win спавн процессов почему-то кардинально дороже, чем в *nix. Если скрипт на питоне потрошит всё сам, не создавая чайлдов, он понятно будет работать быстрее. Как-то пробовал пользовать git-svn на Win — печальное зрелище, клон примерно со скоростью 5-6 ревизий в минуту. На убунте у соседа клон той же репы (~10K ревизий) занял что-то минут 20, не больше. Та же репа с помощью hgsubversion вытянулась у меня на винде минут за 30. Не скажу, что творилось с гитом на убунте (не помню), но на винде он спавнил перл-процесс, который спавнил 4 своих клона, каждый из которых спавнил гит. И эти чайлды постоянно создавались и умирали. Видимо, сказывается другой планировщик плюс отсутствие форка.
Впрочем, мне почему-то кажется, что Вам это и так прекрасно известно
Здравствуйте, Мишень-сан, Вы писали:
МС>Здравствуйте, мыщъх, Вы писали:
МС>В Win спавн процессов почему-то кардинально дороже, чем в *nix.
это понятно, но в данном случае основные тормоза на FindNext в директории с очень большим кол-вом файлов.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>Здравствуйте, Мишень-сан, Вы писали:
МС>>Здравствуйте, мыщъх, Вы писали:
МС>>В Win спавн процессов почему-то кардинально дороже, чем в *nix. М>это понятно, но в данном случае основные тормоза на FindNext в директории с очень большим кол-вом файлов.
Да, точно, припоминаю где-то читал, что вместо простого прохода по узлам там алгоритм Шлемиэля.
Здравствуйте, Мишень-сан, Вы писали:
МС>Да, точно, припоминаю где-то читал, что вместо простого прохода по узлам там алгоритм Шлемиэля.
да нет, с узлами там нормально. я долго искал узкое место профилировщиками разными, экспериментируя с виртуальным диском в памяти, на который все страницы в no-access и потому можно логгировать порядок обращения к ним и время задержки.
получается так, что винда читает данные быстро, а потом задумчимо их обрабатывает. причем, на уровне NTFS задержки вполне приемлимы, а вот дальше где-то случаются большие тормоза. где именно -- так и не выяснил. собственно, у меня была гипотеза, что тормоза связаны с обновлением времени доступа в записях MFT или в журналировании и что если их вырубить, то тормоза исчезнут. хрен там. тормоза где-то в другом месте...
при этом на линухе таких проблем вообще нет. а на виднде пришлось выделить отдельный том для обработки файлов, которые мне присылают на анализ. там их миллионы в одном tar'е. попытка распаковки его на NTFS приводит к тому, что MFT раздувается, пожирая дохрена дискового пространства, а вот обратно после удаления файлов не сокращается. в принципе, есть утилиты которые фиксят эту проблему, но они часто гробят дисковый том. замучавшись с этим -- написал псевдо-драйвер, монтирующий tar как виртуальный диск -- скорость обработки возрасла в сотни раз!!! т.к. у меня tar читается последовательно, а вот винда при поиске FindFirst/FindNext прыгает загадочной траекторией и на мелких файлах 99% времени расходуется на перемещение головки.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
В статье в журнале скорее всего именно борландовский компилер и использовался.
Видимо, придется докупать еще 4 гига оперативки и SSD. 
