Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тормозит. Очень даже тормозит. Жаль мне 56 Мбайт на ровном месте использовать, где один Кбайт нужен. И времени жаль — минуты нет у меня на простенькие операции, где миллисекунды нужны.
ну дык надо просто использовать другие методы, если для тебя вот это место критично. А если ты на каждую мелкую конструкцию смотришь и думаешь "а не будет ли здесь тормозить", то это тот самый premature optimization и будет
PD>Да и не это главное. Но об этом как-нибудь позже — собираюсь изложить свои мысли на этот счет в отдельном выступлении
Здравствуйте, Dyoma, Вы писали: D>Есть замечательный подход: D>1. Пишем продукт на чем удобно => экономим кучу времени на девелопменте, получаем более качественный (по функциональности и фичам) и сопровождаемый продукт. D>2. Профилируем в предельных рабочих условия => мягко говорят тормозит, а точнее стоит и выжирает всю память. D>3. Находим тормозные места. Их всегда мало, написать столько кода что бы проц делающий милиарды операций в секунду не справился невозможно, все сводится к выполнению одного и того же кода в цикле (как вариант рекурсия). D>4. Оптимайзим, если на выбранном языке никак — переписываем, например, на C++. И вылизываем этот код. Задача небольшая, времения на первом этапе сэкономлено много, низкоуровневый язык нас еще не задолбал проблемами типа GPF. D>5. Получаем качественный и быстрый продукт, особо критичные места вылизаны с тщательностью недоступной для тех кто писал на C++ весь проект.
С "замечательностью" подхода согласен... сами так же делаем.
Кстати, по утверждениям авторов, такая штука как Tcl/Tk именно для этого подхода и созавалась (в help-е болше половины текста о том, как "плавно и прозрасно" "опускать" куски кода в С.
Ну и еще на куче хороших и удобных языков можно работать в этом же стиле.
Д>ну дык надо просто использовать другие методы, если для тебя вот это место критично. А если ты на каждую мелкую конструкцию смотришь и думаешь "а не будет ли здесь тормозить", то это тот самый premature optimization и будет
Здравствуйте, VladD2, Вы писали:
H>>>>2) XML диалект для унифицированного описания GUI приложения, чтобы отделить интерфейс от логики и исходных текстов приложения H>>>>3) Везде перейти от абсолютного позиционирования элементов GUI к относительному VD>>>Avalon к твоим услугам. iZEN>>Что значит "абсолютное и относительное позиционирование"? VD>Не_понял почему вопрос ко мне. Но думаю, речь идет о HTML like-стиле.
В общем, проблема проистекает от правильного масштабирования текста, представленного TT-шрифтом: см. Халтурщики в графике
.
Достаточно увеличить разрешение дисплея до 300dpi и применение TT-шрифтов с хинтами и AA станет бессмысленным, вот тогда уже можно будет начать работать с относительным позиционированием элементов и текстовых надписей на них.
iZEN>>И можно ли считать расположение виджетов на форме (в Delphi, к примеру) по принципу выравнивания: "по какому-то краю", "на всю незанятую область" и т.д. — "относительным" позиционированием? VD>Думаю что на 100% нельзя. Все равно ведь привязка к координатам остается в некоторых местах. Хотя это зависит от интерпретации терминов.
Где, интересно? В последних версиях Delphi внедрено свойство для виджетов, позволяющее плавно масштабировать форму и все её элементы при изменении её размеров. Пока что это выглядит удручающе. Наверняка это — влияние принятых парадигм, которые затронуты по ссылке выше.
iZEN>>Менеджеры (Layouts Managers) проблему разве не решают? Напишите свой! VD>Еще раз. Адресуй этот вопрос тому кому отвечал я. Что до меня, то я понимаю разницу между HTML-стилем и менеджерами раскладок, но пережил бы и с последним.
Раз уж дискуссия в этом направлении организовалась между нами тремя, то почему бы не объединить мнения в одном посте?
iZEN>>Что есть "объект" в такой системе? Описание всего класса? А как быть с анонимными классами? VD>Кому вопрос задашь?
Всем.
VD>Ты форум в плоскую читашь, что ли?
Плоско. Ибо лазить по дереву для меня неудобно.
VD>Если речь о том как бы я бы это делал, то отвечу... через AST. Хранение версий исходников действительно можно производить на уровне AST. Но особого смысла в этом не вижу. Текстовые системы хранения версий меня полностью удовлетворяют.
"Текстовые" системы хранения версий не могут понять различия между программными строками, если в них вставлены "оформительские символы" пробел/перевод строки/табуляция, хотя синтаксические конструкции могут быть абсолютно эквивалентными.
Поэтому, надеятся на такие системы — неправильно, ибо первый залетевший "дятел" с лишним пробелом рушит всю систему синхронности исходников, отнимая в том числе человеческие ресурсы.
Нужно идти по пути синтаксического анализа и сравнения исходников, совершенствования систем на этой основе. А что до удобного "представления" кода — это уже на совести сред просмотра кода разработчиком.
Но это в идеале...
iZEN>>В Java есть переменная среды CODEBASE, которая может указывать куда угодно даже во время написания кода. iZEN>>Это ОНО? VD>Чесно говоря завязку на переменные окружения считают не очень удобной... Да и говорил я о другом. Говорил я о ссылках на другие сборки в проектах.
Типа: import, using и т.д.? Но это же тавтология.
iZEN>>Странно, что большое число компаний устанавливают какие-то внутренние "стандарты" оформления кода, когда проблема-то решается на местах "горячей клавишей" в среде того человека, кто этот код читает. VD>Еще одна алогичность. Стандарты нужны для того чтобы код выглядел одинаково. IDE всего лишь позволяют автоматизировать соблюдения эти соглашения. Переформатирование всего кода проекта (особенно если он огромный) приведет к необходимости сболее сложного сравнения версий и скорее всего заливки в систему контроля версий всего содержимого проекта. К тому же это еще и время занимает. Ну, и код приходится смотреть не только из IDE. В том же сорсконтроле, например.
Повторю идею, к которой мы стремимся.
Одинаково код должен выглядеть только для системы контроля версий. На местах разработчиков код должен выглядеть так, как удобно читать и анализировать конкретному человеку (ещё раз: это решается горячей клавишей или предустановками среды конкретного разработчика).
Вот поэтому: iZEN>>Проблема надуманна и раздута.
из-за отказа от синтаксического анализа исходного кода/ресурсов в пользу примитивного текстового сравнения.
Дарней wrote:
> PD>И вот я вижу конструкцию, которая мне подозрительной по > эффективности кажется. И спрашиваю — нельзя ли здесь как-то иначе. > Потому как если начну я просто писать — как бы потом не вышло, что > программа будет работать с неприемлемой скоростью. > Если не тормозит — не оптимизируй!
Чего-то я начинаю в этой истине сомневаться. Слишком часто все "не
тормозит" (или не жрет памяти) в отдельности, но работает со скоростью
улитки (или жрет гигибайты) в целом.
Причем наблюдается это, в основном, у современного софта — та же ICQ без
зазрения совести сжирает 20 метров памяти. Какой-нибудь WinAmp еще 20
метров. Вот так и не остается памяти для чего-нибудь полезного....
Здравствуйте, Cyberax, Вы писали:
C>Чего-то я начинаю в этой истине сомневаться. Слишком часто все "не C>тормозит" (или не жрет памяти) в отдельности, но работает со скоростью C>улитки (или жрет гигибайты) в целом.
C>Причем наблюдается это, в основном, у современного софта — та же ICQ без C>зазрения совести сжирает 20 метров памяти. Какой-нибудь WinAmp еще 20 C>метров. Вот так и не остается памяти для чего-нибудь полезного....
eao197 wrote:
> C>Причем наблюдается это, в основном, у современного софта — та же ICQ > без > C>зазрения совести сжирает 20 метров памяти. Какой-нибудь WinAmp еще 20 > C>метров. Вот так и не остается памяти для чего-нибудь полезного.... > Скорее всего это определяется не языком или фреймворком, а вот этим > замечательным подходом: Re[6]: Следующий язык программирования > <http://rsdn.ru/forum/Message.aspx?mid=1408656&only=1>
, если из него > выбросить пункты со второго по пятый. Потому, что слишком часто на них > времени нет
Даже не то, что бы нет времени — просто еще очень часто сложно выделить
отдельный тормозящий кусок или обеспечить интерфейс остального кода с
оптимизированым куском.
Например (у меня такое было в Java), тормозит сравнение строк без учета
регистра символов. Написать сравнение на С и подключить через JNI —
нельзя, так как сам по себе оверхед вызова внешней функции сожрет
большую часть времени, значит нужно использовать вместо стандартной
строчки какой-то свой велосипед по всему коду с соответствующими
временными затратами.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Что мне хотелось бы обсудить, так это следующее: ЗХ>
ЗХ>I can’t stop asking myself the same question: is it still possible for a new language to make a breakthrough like C and C+ did at the time?
IMHO вопрос поставлен не совсем правильно. Язык это лишь средство решения проблемы, а проблема в том, что программы писать сложно и что бы это было не так сложно нужны удобства. Процедуры и if-then-else удобнее чем макароны из if-goto. Стандратная библиотека удобнее чем самописные алгоритмы. Препроцессор одобен для настройки кода под специфические условия. И т.п.
В этом свете отличие java от C/C++ заключается уже не в упрощенном синтаксисе и managed коде, а так же и, например, в поддержке использования нестандартных библотек. Платформой (не только языком, но и тулами и стандартами) поддержано решение проблемы пространства имен и документации. Я например не помню что бы в C++ проектах использовалось столько нестандартных библиотек, сколько является нормой в проектах на java (про C# не знаю, но наверное ситуация похожа, или по крайней мере движется в ту же сторону). И это уже серьезный шаг вперед и не надо про него забывать.
Собственно а клоню я к тому что "язык" сейчас это уже не только сам язык (синаксис + семантика), а еще и стандарты и инструменты поддерживающие программирование. Более того под языком мы понимаем уже не только платформу, но еще и IDE. Особо заметно это стало с тех пор как IDE перестали быть текстовым редактором с прикрученным дебагером, а поумнели и вместо текстовых файлов стали видеть языковые конструкции.
С тех пор как использование таких фишек как find usages, refactoring и т.п. стали mainstream очень неправильно думать, что все что нужно девелоперу это текстовый редактор и компилятор. Соответственно важны не только фичи самого языка, очень важна поддержка этого языка (набор библиотек, IDE), и плохой (по фичам), но хорошо поддержанный язык имеет больше шансов быть применен. Собственно это мы и наблюдаем вокруг .
Резюмируя все выше сказанное, хочу сказать, что прорыв уже был, просто со времен С эволюционировало сомо понятие "язык программирования".
ЗХ>Так вот, о "language to make a breakthrough". C — тема вообще совсем отдельная (его история слишком тесно переплетена с историей Unix), но вот если взять историю таки "breakthrough", как Fortran и C++, мне бы хотелось отметить некоторые общие моменты:
Далее коментарии в свете вышенаписанно ЗХ>1. вообще говоря, ни тот ни другой язык не были "совершенно новыми": и до Фортрана были попытки создать язык высокого уровня; и до С++ существовали объектно-ориентированные языки.
Тоже самое видим и с IDE refactoring&Co были уже давно, и даже не только в виде академических идей, а так же реализованны для Smalltalk. Когда я увидел первую mainstream IDE работающую с кодом, а не текстом (IntelliJ IDEA 2.0) моей первой мысль было "Ух ты! И для java что-то приличное сделали!"
ЗХ>2. основным свойством и того и другого языка, определившим их популярность, стало приспособление "идей будущего" к "железу настоящего":
Аналог: приспособление идей к языкам настоящего на имеющемся железе. C++ это очень мощный язык, но refactoring для него... (естественно на который можно положиться вне зависимости от того какие извращения мне удобно писать )
ЗХ>- до Фортрана считалось, что любой язык высокого уровня будет порождать слишком неэффективный код; поэтому одной из главных задач команды Фортрана было создание эффективного компилятора
Да-да, регулярные выражения тоже долгое время рулили
ЗХ>- до С++ считалось, что ОО языки — академическая игрушка, не позволяющая писать эффективные программы; одной из главных задач Страуструпа было порождение эффективного кода.
ЗХ>Т.е. и в том и в другом "прорыве" действовала модель "взять уже известные (но все же новаторские) идеи, и создать их эффективную реализацию". Я довольно сильно упрощаю, но общая тенденция, кажется, такова.
Эта же тенденция продолжилась, но в другой сфере.
ЗХ>В современных условиях прорыв такого типа представляется маловероятным, т.к. "железо больше не ресурс": для новых языков программирования вопрос зверской эффективности уже не является определяющим фактом популярности. (В связи с этим фактом интересен "пролет" функциональных языков: когда "железо еще было ресурсом", они заработали ту самую стойкую репутацию "академических поделок", а сегодня — это уже слишком старые идеи, чтобы кого-то увлечь; то же со Smalltalk.)
Они пролетели не потому, что стали не интересны, а потому что очень многим програмерам не вбить в голову идею даже Smalltalk, не смотря на то что он такой же императивный как и широко известный C++, а функциональный подход вообще требует изрядного сдвига мозгов. Достаточно вспомнить когда появился C++ и когда начал появляться объектный код (не путать с кодом с объектами ). Но на C++ можно заниматься структурным программированием, а на Smalltalk уже нет (точнее это будет очень раком ).
ЗХ>Такие дела.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тебе метод Руссиновича перехвата системных вызовов Win32 знаком ? (На всякий случай — это когда в ядре патчится таблица адресов системных вызовов). Метод абсолютно непереносимый, номера функций меняются от одного билда Windows к другому, приходится ссылаться на файлы символов — сам понимаешь, насколько это корректно и т.д. Но другого метода — по крайней мере я не знаю. А этот все же работает, хоть и проблем хватает. Дайте корректный способ — об этом все забудут. Так не дают...
Правада все это имеет не очень большой смысл, так как имеютя отладчики и профайлеры позволяющие и без особых знаний перехватывать вызовы АПИ.
PD>Вот и мои вопросы вовсе не тем объясняются, что не понимаю я идеологию .Net.
Понимаш ли... Когда человек задается вопросами вроде перехвата API-вызвов, то обычно он уже неплохо разбирается в сопуствующих технологиях (платформе Виндовс и ее API, С/С++, отладчиках). При этом он понимает что занимается чистой воды хакерством. Если же такими вещами начинает интересоваться программист, возможно и опытный в дугих делах, но в данной области не опытный, то ничего путного из этого не выйдет. Если же он еще попытается навязать свои привычки в эту новую для него область, то получится просто жудь.
PD> Прекрасно понимаю, и что то, чего я хочу, не вполне корректно — тоже понимаю. Пока меня не припрет по скорости или памяти — я и не подумаю правила нарушать. А вот если припрет — может, и придется. Потому что отказаться от C# я, вполне возможно, и не смогу, а программу делать надо.
Честно говоря мне кажется (будем надеяться, то именно кажется), что программы по C# у вас не выйдет. Ну, нельзя научить других не желая учиться самому. У вас получится антипрограмма.
C# и дотнет это прежде всего коцепция разработки. Если преподавать их багажом WinAPI, то студенты все равно ничего не поймут, а вот откровенное отвращение у них возникнет. Причем отвращение или к преподаваемым технологиям, или к вашему учебному заведению. А может и к тому, и к другому.
PD>И даже не это главное. Вопрос не столько в том, чтобы найти, где можно нарушить. Вопрос-то мой в совсем другом. Я же вижу, что попал в систему, в которой, мягко говоря, несколько иные принципы в плане эффективности исповедуются.
Не исповедуются в ней никакие прицыпы эффективности. В ней принципы надежности и простоты исповедуются. А ты все ищеш эффективность.
PD> Так вот, главное, что я понять хочу — где в ней основные неэффективнсти находятся !!!
А нахрена тебе вообще нужно поднимать вопросы эффективности если твоя задача обучить детей приципам платформы и языка? Нахрена же детей калеками делать?! Ведь преподование дотнета отталкиваясь от эффективности ты именно маральных уродов из них и сделашь!
Пойми же ты, что эффетивность кода даже в С и С++ является областью продвинутых знаний. Эта область напрямую свзяана с особенностями реализации компиляторов, процессоров и т.п. Ну, нельзя это все вываливать на людей с нулевым багажом.
Твоя задча дать им знания в области безопастного программирования, архитектуры, паттернов решения часто встречающихся задач и т.п. А эффективность можно разбирать только когда они уже уверенно будут программировать на этом языке/платформе.
PD> Когда я в С++ програмирую, я всегда знаю, что мне та или иная конструкция стоить будет.
Нифига ты не знашь. Все зависит от тонны факторов. Только на конкретной платформе, с кокретным компилятором и конкретным процессором ты можешь что-то сказать уверенно. И то для этого нужен конкретный опыт.
Точно так же я программируя на C# под дотнетом могу что-то сказать о производительности зная что за процессор, версия фрэймворка и т.п. используются.
PD> А здесь — пока не знаю.
Дык, пока что ты начинающий в этой области. Поварись с наше и ты начнешь понимать, что дешево, а что дорого.
PD> И вот я вижу конструкцию, которая мне подозрительной по эффективности кажется.
Так расслабся и думах о хорошем. Всеравно фиг ты что угадашь.
PD> И спрашиваю — нельзя ли здесь как-то иначе.
Нельзя. Вернее катигорически не нужно. Причем просто потому, что твоя погоня за мнимой эффективностью кода, ты выплескиваешь ребенка. Ты пыташся программировать на безопастном и простом языке сложно и глупо.
PD>Потому как если начну я просто писать — как бы потом не вышло, что программа будет работать с неприемлемой скоростью. Подводные камни я найти хочу и знать о них заранее...
Когда потом? Ты программу хочешь тесировать после того как полностью допишеш ее код? Нет ведь. Ты ее постоянно запускаешь и тестируешь. Ту, так что ты не видишь насколько быстро работает твой код?
Ну, а узкие места нужно искать профайлрами. Лучше бы про них в своей курс что-то включил. Ну, а со временем получишь опыт и будешь заранее примерно знать что во что обходится. Но все равно на 100% ты никогда ни в одной програмее не скажешь где все узкие места.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, не согласен. C#, что бы там его адепты не говорили, есть несколько модифицированный C++. И именно поэтому у меня возникли проблемы с перенесением привычных понятий в Шарп. А вот если дадите мне принципиально новый язык и убедите, что им заниматься стоит — я отрину все, что я знаю, вспомню себя в молодости и начну его изучать, как будто я ничего не знаю.
Бери. Завут язык Хаскель. Но боюсь он тебе покажется полнейшим извращением. Тут если до этого функцинальным программированием не занимался, то прийдется ломать не привычки, миросозерцание.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Нет, не согласен. C#, что бы там его адепты не говорили, есть несколько модифицированный C++. И именно поэтому у меня возникли проблемы с перенесением привычных понятий в Шарп. А вот если дадите мне принципиально новый язык и убедите, что им заниматься стоит — я отрину все, что я знаю, вспомню себя в молодости и начну его изучать, как будто я ничего не знаю.
AVK>Забавный ты человек. Тебе говорят, что C# это совсем не C++, что окромя синтаксиса, между ними мало общего. Ты не веришь, набиваешь себе шишки, но при этом продолжаешь гнуть старое.
Дык, эта... У ёжиков учится.
-----------------
Ёжики плакали, кололись, но продолжали жрать кактус.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, AndrewVK, Вы писали:
AVK>>Не новое, а другое. Не переиначивай мои слова.
PD>Другое — согласен. Но прочти еще раз мой ответ Зверьку. Я же там ясно писал
>> в некотором смысле Java и C# не есть нечто совершенно новое по сравнению с Фортраном.
А С++ по сравнению С. Ну, право что там нового? А АОП, Шаблоны, перегрузка... это все мелочи.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Dyoma, Вы писали:
D>Я например не помню что бы в C++ проектах использовалось столько нестандартных библиотек, сколько является нормой в проектах на java (про C# не знаю, но наверное ситуация похожа, или по крайней мере движется в ту же сторону). И это уже серьезный шаг вперед и не надо про него забывать.
Я не помню, когда бы я использовал в C++ больше двух стандартных библиотек: libc и STL. Все остальные библиотеки совершенно не стандартны.
D>Собственно а клоню я к тому что "язык" сейчас это уже не только сам язык (синаксис + семантика), а еще и стандарты и инструменты поддерживающие программирование. Более того под языком мы понимаем уже не только платформу, но еще и IDE. Особо заметно это стало с тех пор как IDE перестали быть текстовым редактором с прикрученным дебагером, а поумнели и вместо текстовых файлов стали видеть языковые конструкции.
Имхо, это все равно такой же "язык", каким был раньше. Из-за того, что ты перешел с C++ на Java твой стиль мышления в корне не изменился. Как мыслил ты объектами и объектными паттернами, так и продолжаешь. Только детальки различаются.
А вот если бы ты перешел на какую-нибудь новую парадигму (как это было при переходе от процедурного к объектному подходу) вот тогда бы мышление менять пришлось. И все эти фенечки, вроде IDE и стандартных всеобъемлющих фреймворков, показались бы так -- конфети под ногами.
И новый язык обязательно появится. Может быть его зачатки уже где-то рядом. Тот же Duck typing
E>Я не помню, когда бы я использовал в C++ больше двух стандартных библиотек: libc и STL. Все остальные библиотеки совершенно не стандартны.
По идее, имеется ввиду стандартное использование нестандартных библиотек.
т.е. имеется ввиду частое использование чужих библиотек с именем(широко зарекомендовавших себя) и которые при этом не входят в стандартную поставку.
например, под C++ так сразу могу только вспомнить из тех, что мы, например, использовали или рассматривали для использования: boost, stingray.
для C#: MagicLibrary (док-контролы), Steema TChart (графики), NineRays Report (отчеты), NullableTypes и т.д.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>О господи, да когда же вы перестанете везде наезды искать ?
А разве это не наезды?
PD>Давай вот что сделаем! Ладно, с моей стороны — это наезды . Прекрасно, давай тогда расскажи ты (или другие гуру от дотнета), что в ней плохо. Что в ней явно хуже, чем в неуправляемом коде.
Я долго думал что же в ней плохого, нашёл кучу недостатков, но когда начал писать понял, что это всё то, чего бы мне ещё хотелось иметь, но никак не "явно хуже, чем в неуправляемом коде". Так что я сдаюсь Явно хужего я не нашёл. Хотя пожалуй есть пара недостатоков:
1) Любит память, иногда потребляет её столько, что любители выжимать биты из байтов при виде этого падают в обморок.
2) Требует установки 20 мегабайтного фреймворка, что способствует замедлению распространения.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Dyoma, Вы писали:
D>Есть замечательный подход: D>1. Пишем продукт на чем удобно => экономим кучу времени на девелопменте, получаем более качественный (по функциональности и фичам) и сопровождаемый продукт. D>2. Профилируем в предельных рабочих условия => мягко говорят тормозит, а точнее стоит и выжирает всю память. D>3. Находим тормозные места. Их всегда мало, написать столько кода что бы проц делающий милиарды операций в секунду не справился невозможно, все сводится к выполнению одного и того же кода в цикле (как вариант рекурсия). D>4. Оптимайзим, если на выбранном языке никак — переписываем, например, на C++. И вылизываем этот код. Задача небольшая, времения на первом этапе сэкономлено много, низкоуровневый язык нас еще не задолбал проблемами типа GPF. D>5. Получаем качественный и быстрый продукт, особо критичные места вылизаны с тщательностью недоступной для тех кто писал на C++ весь проект.
Подход очень правильный... во многих случаях... Но...
1. Для "любого" средства банально может быть недоступен профайлер. Или доступен, но такой, что считай, что его нет.
2. Про задачу может быть заранее известно, что в ней слишком много нужно оптимизировать. Ну, опять же приведем в пример вычислительные задачи. Что толку искать в таких задачах узкие места профайлером? Он их конечно найдет, но это будет 80% кода.
3. Если мест требующих оптимизации на другом языке относительно много, то гемороем может стать сама интеграция. Так же если мест 1-2 может оказаться неприятным таскать за собой чужеродные для основного средства разработки модули. Ну, и вообще чем больше интеграции тем болше проблем и гемороя.
VD>>Да нет. Это не глупость. Но согласен, что трудозотраты для "быстрых" языков будут несоизмеримо больше, а вот реальный выигрышь не сильно. Ну, а реально скорее всего "быстрые" языки сядут на алгоритмах которые поленились оптимизировать программисты погрязшие в подробности "быстрых" языков.
D>Не только на алгоритмах, но и на архитектуре. Например наличие GC расширяет выбор архитектур просто за счет того что снимает вопросы типа "А когда это объект должен сдохнут?" "Как бы освобождать память и не нарываться на GPF?" и т.п.
Я и не спорю. Просто ты видимо пропустил мое замечение:
Это одно и тоже. Архитектура — это алгоритм на очень высоком уровне асбтракции. Но в целом согласен.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Dyoma, Вы писали:
D>Есть замечательный подход: D>1. Пишем продукт на чем удобно => экономим кучу времени на девелопменте, получаем более качественный (по функциональности и фичам) и сопровождаемый продукт. D>2. Профилируем в предельных рабочих условия => мягко говорят тормозит, а точнее стоит и выжирает всю память.
Обычно после вот этого весь подход и заканчивается
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
PD>Если бы я знал, какая еще мелкая конструкция может дать 14-кратное замедление...
Пока не наступишь в лужу, не узнаешь ее глубину На C++ ты тоже не можешь знать точно, какая мелкая конструкция может дать какое замедление. Завтра выйдет новый компилятор или новая модель процессора, и все твои усилия по оптимизации каждого куска кода могут пойти лесом.
Здравствуйте, eao197, Вы писали:
E>Скорее всего это определяется не языком или фреймворком, а вот этим замечательным подходом: Re[6]: Следующий язык программирования
, если из него выбросить пункты со второго по пятый. Потому, что слишком часто на них времени нет
Плюс нужно учитывать, что унаследованный код во многих продуктах имеет многолетнюю историю. За всё это время на него накладывались такие слои заплаток, что никто уже не знает толком, как оно на самом деле работает Говорить о каком-то профилировании или оптимизации в этом случае и не приходится.
Здравствуйте, Cyberax, Вы писали:
C>Чего-то я начинаю в этой истине сомневаться. Слишком часто все "не C>тормозит" (или не жрет памяти) в отдельности, но работает со скоростью C>улитки (или жрет гигибайты) в целом.
C>Причем наблюдается это, в основном, у современного софта — та же ICQ без C>зазрения совести сжирает 20 метров памяти. Какой-нибудь WinAmp еще 20 C>метров. Вот так и не остается памяти для чего-нибудь полезного....
Если нам не помогут, то мы тоже никого не пощадим.
