Здравствуйте, AndrewVK, Вы писали:
AVK>>>Это GUI приложение. Никаких потоков там нет.
TK>>Сегодня нет, а если завтра появятся?
AVK>Не появятся. Городить double check locking на всякий случай имхо перебор. И производительность это, кстати, ухудшит.
Вот индус, написавший код XmlSchemaCollection, тоже так же думал, что никто часто схемы грузить не будет
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если же оставаться на нынешней стадии, то все же ИМХО скорость БД будет поменьше. Подчеркиваю — ИМХО, это не личный опыт, а скорее отзывы, какие я получил. Я, когда над своим проектом начал работать (а было это 4 года назад) первым делом задал вопрос в фидо конференции по БД — так и так, есть такие-то данные, можно ли с помощью БД получить доступ за 50-70 мсек, если да — какую БД посоветуете ? Ответ был единодушный — нет. Может, они не правы были, к тому же с тех пор прошло 4 года...
Используя локальные БД и низкоуровневое API легко. По сути ни чем не отличающейся от прямого доступа. Но легко строить объектную надстройку.
... << RSDN@Home 1.1.4 stable rev. 510>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, peterbes, Вы писали:
P>Здравствуйте, Pavel Dvorkin, Вы писали:
P>[offtopic] P>Павел, коллега, вы похоже пытаетесь вывести некие универсальные законы которые должно воспринимать как некие откровения. Может быть мой опыт программирования и не столь велик и писать программы я стал в зрелом 32-х летнем возрасте, но если бы мне пришлось мучиться такими парадигмами, то уверен, что дальше задачи написания программы Hello_World.exe дело бы не сдвинулось. У меня нет опыта преподавания, потому мое мнение сугубо дилетанское — нет нужды загружать чужие мозги задачами которые не кричат, у всех своя голова, как и кто будет решать конкретную задачу зависить от обстоятельств и от человека.
Золотые слова.
Думать студентов учат на таких дисциплинах, как: матанализ, линейная алгебра, функциональный анализ и т.п.
Программирование — это прикладная дисциплина, индустрия, тут надо больше делать, чем думать.(Я не говорю, что не надо думать, просто обычно надо думать сугубо практически, над конкретной задачей)
Здравствуйте, TK, Вы писали:
TK>Этот случай надо запомнить. Хотя, можно было-бы и на этапе проектирования прикинуть, что валидация сложного XML документа может быть достаточно ресурсоемким заданием.
Запомнить нужно не этот случай, а то что проблемы могут не поддаваться учату зараннее. И профайлер позволяет их найти.
Как, по-твоему, АВК мог б узнать об этой проблеме не включая профайлер? Его код ведь практически идеален. Проблема в бибилиотеке.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кстати, у VC компилятора есть несколько базовых режимов оптимизации — Minimal size, Maximum Speed. К чему бы это ? . Они что-то тоже не хотят сказать, что важнее.
А ты их переключи, и вместе посмеемся над разницей.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 0rc, Вы писали:
0rc>Так вот, мы посчитали, что 25 тыс. загруженых (5Мб файл) записей из CDR-файлов(для тех кто с биллингом не работал, это такие CSV-файлы) с обработкой и последующей записью занимает 2 мин. 14 сек. Далее характеристики двух дней оптимизации: 0rc>
0rc>Точка отчета: 2 мин. 14 сек.
0rc>(А)Очередь симметричных запросов: 2 мин. 05 сек.
0rc>(АР)Резервирование памяти, под
0rc> "узнаваемые" данные: 2 мин. 00 сек.
0rc>(А)Замена map vector-м 1 мин. 54 сек.
0rc>(АР)Замена строк хэшем 1 мин. 30 сек.
0rc>(АР)Запись в файл через буфер строк,
0rc> вместо записи vector-а строк в поток 42 сек (запись в 5 МБ в файл=0.05 сек)
0rc>(А+АР)далее...: 15 сек
0rc>
0rc>АР — архитектурное решение примененено, 0rc>А — применен алгоритм 0rc>Если раньше модуль накапливал данные днем и обрабатывал ночью, то теперь он все успевает, более того модуль отдает больше CPU времени для своих нужд. Для нас вышло, что выигрыш одной сек на операции — это выйгрыш ~12 мин в день. Это здорово, так как заказчики "писают кипятком", а "конкуренты кусают локти"
Что характерно в оптимизациях только архитектура и алгоритмы. А вот соплей на которые тут так часто указывают коспода сами знаете кто что-то не видно. Видимо если вместо строк попользовать буферы в стеке, то приложение начнет вознващать время процессору (ну, давать отрицальные величины по времени)
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
TK>> Хотя, можно было-бы и на этапе проектирования прикинуть, что валидация сложного XML документа может быть достаточно ресурсоемким заданием.
AVK>Можно. Только это не помогло бы. Каким бы не был медленным валидатор, он явно не должен тратить несколько секунд на валидацию пары десятком килобайтных XML-файлов.
Извини, я так не пойму к чему ты все это говоришь? Если на жизнь жалуешься то, это не ко мне...
Ты привел свой пример здесь
. Так, я совершенно не спорю, что кривые руки они и в африке кривые руки. В библиотеках они тоже могут встречаться. Да, к выбору базовых библиотек тоже надо подходить аккуратно. Собственно, твой пример один в один история влада. Только, ты не стал делать макаронный код, а решил исходную проблему. О чем речь то? Не спорю, правильно. Да, такую задачу проще решить профайлером — тоже не спорю.
AVK>>>Относится очень просто — как пример того, что этот маленький кусочек кода способен сделать бесполезными горы оптимизаций, причем от таланта архитектора или программиста это практически не зависит.
Так кто говорит, что надо сразу делать все опитимизации. мой поинт был в том, что в некоторых случая просто не надо лениться, а сразу писать нормально. Вполне возможно, что тогда и профайлером пользоваться не придется.
TK>>Именно по этому, надо нормально писать даже самые маленькие кусочки.
AVK>Павел же понимает под эффективностью потребление процессора и памяти, причем никак не хочет сказать что важнее.
Это от ситуации зависит. Иногда, важнее надежность Или, у тебя универсальное решение есть?
TK>>Сегодня нет, а если завтра появятся?
AVK>Не появятся. Городить double check locking на всякий случай имхо перебор. И производительность это, кстати, ухудшит.
Сделай readonly поле которое будет инициализироваться методом GetMetadataSchema. Даже, один LOC съэкономить можно. Что до того, что производительность ухудшит так, если есть два варианта производительность vs надежность то, лучше выбирать надежность (если конечно, софт не одноразовый)
AVK>А я не тебе, я тому товарищу, просто напрямую обратится не имею возможности.
Хочешь, я адрес дам куда жаловаться?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
КДВ>>Таких списков можно насоставлять море.
IT>Так вот и надо их насоставлять. И боюсь блочного чтения там может и не оказаться
А это уже зависит от предметной области, в которой человек силен и разбирается лучше всего. Я, к примеру, буду упор на структуру БД делать в первую очередь. Твоя очередь...
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>И не скажу, не жди. Потому как вопрос из той же серии — что лучше : список или массив ?
AVK>Но тогда как следовать твоему лозунгу?
Какому лозунгу ? Я 33 раза говорил, что ни к какой оптимизации всего и вся я не призываю и 100 раз говорил, что истина конкретна. Если ты где-нибудь найдешь, что я призывал любой ценой и все, что угодно оптимизировать — покажи.
AVK>Здорово. А если еще вспомнить, что помимо памяти и процессора есть еще ряд немаловажных критериев и подставить их в вышеотквоченое, то спорить будет вобще не о чем.
NC>Думать студентов учат на таких дисциплинах, как: матанализ, линейная алгебра, функциональный анализ и т.п.
NC>Программирование — это прикладная дисциплина, индустрия, тут надо больше делать, чем думать.(Я не говорю, что не надо думать, просто обычно надо думать сугубо практически, над конкретной задачей)
Ну вот, дошли до точки. Оказывается, программисту надо больше делать, чем думать. А если думать — то только сугубо практически. И учить студентов думать я не должен. Все ясно.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, IT, Вы писали:
IT>>Давайте в качестве жирной точки данной темы перечислим более менее удачные случаи оптимизации.
IT>А что такое? Никому нечего сказать? Никто никогда ничего кроме побайтового ввода не оптимизировал?
Так для проектов критичных к быстродействию может оказатся проще написать что не оптимизировал. Тем более при правильном проектировании таких программ сама их архитектура подчиняется требованиям быстродействия и оптимизаций подобных оптимизациям из твоего списка практически не требуется.
[ваш флейм] PD>Ну вот, дошли до точки. Оказывается, программисту надо больше делать, чем думать. А если думать — то только сугубо практически. И учить студентов думать я не должен. Все ясно.
[мой флейм]
Павел, одни преподаватели байки про свое бурное героическое прошлое гонят, как я на коленчке дырки на перфокарте колол и весь в синячках ходил и как я программку дипломную писал или как я на синтез хыфы-трицикло-мыгы-тетрагыгы фенилтетраметанана 140 часовой проводил будучи аспирантом и жил в лаборатории месяц безвылазно, другие не вещают, а бьют смертным боем несчастных студентов. К одним ходят на экзамет как на праздник, к другим идут как твари на закланье. Ни те не другие не учат, словеса которые произносят ученые мужи теряются в стенах БХА-БФА и прочих аудиториях, "покложить на них всех с прибором", вот единственная задача студента. Когда интересно, тогда их слушаешь, когда не интересно — спишь или в шахматы играешь. Реально учатся уже после получения диплома, на этот раз, действительно на совесть, база есть, дальше сам двигайся. База, как ни пародоксально, это не акадимические мужи с их бу-бу-бу, база это твои чистолюбивые и абициозные сокурстники и та среда которая заставляет тебя быть лучше других хоть в чем-то.
P>Павел, одни преподаватели байки про свое бурное героическое прошлое гонят, как я на коленчке дырки на перфокарте колол и весь в синячках ходил и как я программку дипломную писал или как я на синтез хыфы-трицикло-мыгы-тетрагыгы фенилтетраметанана 140 часовой проводил будучи аспирантом и жил в лаборатории месяц безвылазно, другие не вещают, а бьют смертным боем несчастных студентов. К одним ходят на экзамет как на праздник, к другим идут как твари на закланье. Ни те не другие не учат, словеса которые произносят ученые мужи теряются в стенах БХА-БФА и прочих аудиториях, "покложить на них всех с прибором", вот единственная задача студента. Когда интересно, тогда их слушаешь, когда не интересно — спишь или в шахматы играешь. Реально учатся уже после получения диплома, на этот раз, действительно на совесть, база есть, дальше сам двигайся. База, как ни пародоксально, это не акадимические мужи с их бу-бу-бу, база это твои чистолюбивые и абициозные сокурстники и та среда которая заставляет тебя быть лучше других хоть в чем-то.
это имхо в варианте плохих преподавателей. К сожалению, их больше чем хороших. И с каждым годом эта тенденция усиливается.
Мне повезло у меня были и хорошие преподаватели.
Как ни странно, хороший преподаватель не специально "учит думать", а преподносит свой материал в таком ключе, что ты волей-неволей научишься думать как надо.
А когда проеподаватель постоянно скатывается на описание случаев из своей жизни, то это п..бол, а не преподаватель (не будем показывать пальцем).
Здравствуйте, OnThink, Вы писали:
OT>это имхо в варианте плохих преподавателей. К сожалению, их больше чем хороших. И с каждым годом эта тенденция усиливается. OT>Мне повезло у меня были и хорошие преподаватели. OT>Как ни странно, хороший преподаватель не специально "учит думать", а преподносит свой материал в таком ключе, что ты волей-неволей научишься думать как надо. OT>А когда проеподаватель постоянно скатывается на описание случаев из своей жизни, то это п..бол, а не преподаватель (не будем показывать пальцем).
Преподователь от Бога, особая категория профессионалов. Начнешь считать их, и пальцев одной руки хватит. Истинное счасть учиться у этих людей. Сдется мне, что количество их величина постояная и не от чего не зависящая.
Здравствуйте, VladD2, Вы писали:
VD>Видимо если вместо строк попользовать буферы в стеке, то приложение начнет вознващать время процессору (ну, давать отрицальные величины по времени)
В точку. Мы иногда так и отшучиваемся — еще чуть-чуть оптимизации и модуль будет работать в будущем
Здравствуйте, IT, Вы писали:
IT>Думаю таких примеров может каждый наприводить Давайте в качестве жирной точки данной темы перечислим более менее удачные случаи оптимизации.
Был написан модуль, делающий посимвольный парсинг небольшого файла (что-то типа хмл), представление его в обьектном виде, интерфес для программной правки обьекта (или создание с нуля) и запись в файл. Файл свободно помещался в памяти.
Профайлер показал мелкие недочеты с моей стороны и главное то, что куча времени тратилась на оператор вывода символа в поток:
outstream << ch;
Анализ кода библиотеки показал, что там куча такого что мне не нужно. Заменил на
Здравствуйте, IT, Вы писали:
IT>А что такое? Никому нечего сказать? Никто никогда ничего кроме побайтового ввода не оптимизировал?
А что говорить тут? Ты все правильно написал:
1. Bulk execute у нас уже был. Поэтому основных проблем не возникло. Хочу остановиться по подробнее на этом. Мы написали свой аналог OCCI, назвали его OCCIX. В основном преследовались две цели: (1) Уйти от OCI и CC к GCC 3.x и объектному интерфейсу. (2) Получить открытый исходник OCCIX. Поскольку полностью все вызовы, функции, параметры, классы и т.д. были одинаковы с OCCI. Мы получили полный аналог OCCI в плане интерфейса. Да и разработка не больно много заняла — всего неделя. Были мелкие ошибки — например, порядок байт в слове различен — но это быстро выявилось, да и ошибок было таких 1-2. Плюс получился очень интересный эффект — после разработки "велосипеда" мы имели по нем документацию на 800 стр.
2. PL-SQL нам так же хорошую службу сослужил. В другом модуле у нас было множество функций, написаных на ProC с ними постоянно в режиме "спагетти-кода" взаимодействовало где-то 10-15 Си-функций: свои велосипеды контейнеров на Си и все такое прочее. Было принято волевое решение — переписать модуль на С++ с использованием STL: в коде стали вырисовыватся объекты и слои. После оказалось, что слои полностью независимы. Итог: один из слоев мы перенесли полностью в PL-SQL. Сам исходный код модуля значительно уменьшился и стал намного лучше читатся.
3. Насчет временных таблиц — мы пришли к этому сразу (до стадии разработки). По началу меня бесило работа с временной таблицей на 130 колонок. Но после исследования (тут надо сказать о некоторой безолаберности в отношении моих предшественников: на 140 таблиц не было ни грамма документации) самой практики взаимодействия модулей. Конечно после 3G-систем, где все взаимодействие было через метаданные, абстракции и слои в БД — решение временной таблицы на 130 колонок, вначале смахиволо на идиотизм. Но после я разобрался почему такое решение было принято.
4. По поводу сортировки. Был один тонкий момент — перед выгрузкой нам подребовалось отсортировать курсор по колонке. Поскольку все тестировалось на тестовом сервере — мы физически не могли на тестовом сервере воспроизвести такую ситуацию, — у нас не было доступа к NE. Мы могли только сделать мелкий тесты регрессии на отдельных схемах. Когда же мы запустили на продакшене — оказалось, что сортировка курсора значительно тормозит — и нам пришлось отказатся от нее.
5. Отображаемые файлы у нас стоят на повестки дня — если понадобится еще увеличить производительность, то это следующий наш "козырь в борьбе за выживание". Пока мы их не применяли.
Здравствуйте, IT, Вы писали:
IT>>Давайте в качестве жирной точки данной темы перечислим более менее удачные случаи оптимизации.
IT>А что такое? Никому нечего сказать? Никто никогда ничего кроме побайтового ввода не оптимизировал?
Ну почему же... Большинство оптимизаций относятся к работе БД...
Случаев масса, правда в большинстве своем изначально нужно было руки разработчикам отрывать, чтобы они такого не писали Причем что характерно, изменение скорости обычно составляет порядок, если не два порядка
Из комплексных оптимизаций...
Массовая обработка объектов в БД. Начальное время работы — порядка 4 часов. Требуемое время работы — 20 минут.
— Замена сервера и RAID-массива — стало 1.5 часа
— Убрали дублирующие перерасчеты — примерно 1 час
— Изменили алгоритмы обработки с общих на частные случаи, основанные на полученной информации о характере обрабатываемых объектов — стало 30 минут
— Запуск обработки в несколько потоков — 19 минут (но т.к. все остальные процессы стали притормаживать, от этого отказались)
— Изменение размера страницы сервера на 8к — стало 19 минут. Т.к. уложились в тербуемое время, оптимизацию остановили.
Если нам не помогут, то мы тоже никого не пощадим.
