Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>А причем тут пользователи? Речь о программистах.
PE>Т.е. пользователи сук и быдло
Я этого не говорил.
PE> и не могут интесеваться производительностью ПО
Может. Но шустрики не для него.
PE> за которое платят деньги ?
Пользователь платит деньги за компиляторы? Это что то новенькое.
AVK>>Компилятором оно определяется в последнюю очередь. Если интересна производительность конкретного софта то ее и надо сравнивать, а не компиляторы, на которых оно компилировалось.
PE>Вот я и хочу сравнить перформанс двух прилаг — нативной ужималки и такой же, но менеджед. PE>Мне дают диск на двадцать минут. Есть возможность взять прилу подешевле, но менеджед, или подороже, но нативную. PE> Какой ужималкой я смогу ужать за 20 минут весь аудиодиск?
Думается мне что реализация и алгоритмы в данной ситуации значительно важнее нежели использованные компиляторы. Ты вот навскидку, не гляда скажи — на каком компиляторе скомпилирован декодер винампа? Наверняка не ответишь. Я вот точно не знаю. Потому что мне пофигу. А уж среднестатистический пользователь просто не сможет на этот вопрос ответить.
PE>>> Ибо тормозное глюкало писать не хочется. AVK>>Т.е. какие то компиляторы всегда делают тормозное глюкало?
PE>Конечно. Но не только компилеры. Среда тоже может "помочь".
Среда выполнения в смысле? Ну то есть на дотнете можно написать только тормозное глюкало, ты это хочешь сказать? Я твою мысль понял. Т.е. из ненависти к дотнету, на котором тебя заставляют писать глупые начальники ты очень хочешь добавитьтакой тест чтобы дотнет на нем выглядет как можно хуже. Так что ли?
AVK>>Так алгоритмы или процессоры? Какое имеет отношение сравнение производительности процессоров к сравнению производительности компиляторов?
PE>Нужно перегнать DVD в MPEG4. PE>Ты платишь за время бабло — 3$ в час допустим. PE>И есть выбор в железе, в компилерах, в среде, в джите, если есть. PE>Задача — определить, на какой конфигурации можно получить минимальные временные затраты.
Так, понятно чем ты на работе в качестве программиста занимаешься.
Напоминаю в который уже раз — в шустриках никто не тестирует и не будет тестировать процессоры и прочее железо, а так же конкретный прикладной софт для обработки звука и видео. Там тестировали и тестируют компиляторы.
Здравствуйте, AndrewVK, Вы писали:
PE>>не могут интесеваться производительностью ПО за которое платят деньги ? AVK>Пользователь платит деньги за компиляторы? Это что то новенькое.
Компилятор влияет на производительность ПО. Так понятнее. И не выдергивай слова из фразы.Это не к лицу модератору.
PE>>Вот я и хочу сравнить перформанс двух прилаг — нативной ужималки и такой же, но менеджед. PE>>Мне дают диск на двадцать минут. Есть возможность взять прилу подешевле, но менеджед, или подороже, но нативную. PE>> Какой ужималкой я смогу ужать за 20 минут весь аудиодиск?
AVK>Думается мне что реализация и алгоритмы в данной ситуации значительно важнее нежели использованные компиляторы. Ты вот навскидку, не гляда скажи — на каком компиляторе скомпилирован декодер винампа? Наверняка не ответишь. Я вот точно не знаю. Потому что мне пофигу. А уж среднестатистический пользователь просто не сможет на этот вопрос ответить.
Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.
PE>>>> Ибо тормозное глюкало писать не хочется. AVK>>>Т.е. какие то компиляторы всегда делают тормозное глюкало?
Конечно. Это в ваших шустриках и написано, что одни компилеры дают шустрый код, другие тормозной.
AVK>Среда выполнения в смысле? Ну то есть на дотнете можно написать только тормозное глюкало, ты это хочешь сказать? Я твою мысль понял. Т.е. из ненависти к дотнету, на котором тебя заставляют писать глупые начальники ты очень хочешь добавитьтакой тест чтобы дотнет на нем выглядет как можно хуже. Так что ли?
Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++, если за нее заплатят деньги и при этом критичен перформанс.
PE>>Нужно перегнать DVD в MPEG4. PE>>Ты платишь за время бабло — 3$ в час допустим. PE>>И есть выбор в железе, в компилерах, в среде, в джите, если есть. PE>>Задача — определить, на какой конфигурации можно получить минимальные временные затраты. AVK>Напоминаю в который уже раз — в шустриках никто не тестирует и не будет тестировать процессоры и прочее железо, а так же конкретный прикладной софт для обработки звука и видео. Там тестировали и тестируют компиляторы.
Отлично. Сделаем по твоему. Процессоры одинаковые и железо одинаковое.
Осталось сравнить три продукта (нативный, дотнетовский, жавовский).
Здравствуйте, AndrewVK, Вы писали:
PE>>А при чем здесь COM ? AVK>Вот и я о том же.
Про COM ты сам вспомнил. Я ничего не говорил. Я предложил идею реализации, аналогичную комовской.
PE>> Я описываю в дотнете интерфейсы, который диктуют аналогичную функциональность. Вот и все. А с COM скрещивать я ничего не собираюсь.
AVK>Тогда какое это имеет отношение к замене событий интерфейсами?
Это ты предложил интерфейсы и даже собственную реализацию привел.
PE>>Вот это я тебе и хотел показать. AVK>При помощи еще одного класса? Странный однако ты выбрал способ сделать это.
PE>>>>Для каждого члена класса нужно писать свою имплементацию интерфейса обратного вызова. AVK>>>Это практически равносильно написанию обработчика события.
PE>>Вовсе нет. Интерфейс нужно объявлять полностью.
AVK>Что значит объявлять полностью?
PE>> А обработчики ты можешь вовсе опустить.
AVK>Не, чего то я тебя не пойму. Если тебе обработчики нужно опустить ты и интерфейс не реализуй.
PE>>Еще нужна инициализация хитрая в конструкторах.
AVK>Что то в моем примере никакой хитрой инициализации нет. Ты о чем вобще?
AVK>>>Ну и где здесь разница? Вместо +-= будут вызовы Add/Remove. Не думаю что такая замена сильно скажется на объеме работ.
PE>>А конструкторы ? AVK>Что конструкторы?
А в конструкторах по твоему методу нужно приинициализировать все инстанцы, которые заведуют оработкой событий от объекта i-ой проперти. Им нужно this сообщить.
PE>>>>В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку. AVK>>>К счастью на шарпе не сильно.
AVK>Так надо так строить приложение чтобы легко было имитировать внешнюю среду для отдельных блоков. Еще юнит тестирование в таких случаях рулит.
Для сетевой модели сложность написания тестов O(n**2). Вперед !
Так что внешние тесты подходят только на начальной стадии разработки, когда реализются базовые механизмы:
1. Коллекции
2. Механизм отписки-подписки
3. Простую валидацию
Загрузку и сохранение уже не протестируешь не говоря об самых маленьких алгоритмах.
PE>> Есть выход — винраннер подключить. AVK>Не знаю кто такой.
Это прила для тестирования других прил
PE>> Но для него тож скрипт нужен. AVK>А вы как вобще отлаживаетесь? Или вы сразу без ошибок пишете?
Конечно отлаживаемся. Но перенос отлов ошибок в ранайме достает неслабо.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>не могут интесеваться производительностью ПО за которое платят деньги ? AVK>>Пользователь платит деньги за компиляторы? Это что то новенькое.
PE>Компилятор влияет на производительность ПО.
Влияет. Только шустрики не об этом.
PE>И не выдергивай слова из фразы.Это не к лицу модератору.
Во-первых это демагогия. Во-вторых я как нибудь сам определюсь что мне к лицу. В-третьих тот кто это письмо читает наверняка читал предыдущее, а если нет то без проблем прочитает, так что оверквотинг разводить не имеет смысла.
PE>Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.
Вот только шустрики не о производительности декодеров mp3.
AVK>>>>Т.е. какие то компиляторы всегда делают тормозное глюкало?
PE>Конечно. Это в ваших шустриках и написано, что одни компилеры дают шустрый код, другие тормозной.
А про глюки там тоже написано или ты для красного словца?
PE>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++,
На этот вопрос сможешь ответить только ты сам.
AVK>>Напоминаю в который уже раз — в шустриках никто не тестирует и не будет тестировать процессоры и прочее железо, а так же конкретный прикладной софт для обработки звука и видео. Там тестировали и тестируют компиляторы.
PE>Отлично. Сделаем по твоему. Процессоры одинаковые и железо одинаковое. PE>Осталось сравнить три продукта (нативный, дотнетовский, жавовский).
Вот и возвращаемся к исходному вопросу — нафига там тестировать алгоритмы упаковки звука, если процент программистов, на которых эта статья нацелена, занимающихся звуком весьма мал?
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>А при чем здесь COM ? AVK>>Вот и я о том же.
PE>Про COM ты сам вспомнил.
Ага, и Влад тоже, синхронно со мной. А ты как бы про него даже не писал.
PE> Я ничего не говорил.
Цитату привести?
AVK>>Тогда какое это имеет отношение к замене событий интерфейсами? PE>Это ты предложил интерфейсы и даже собственную реализацию привел.
Предложил не я. Я тебе ответил на вопрос как примерно это можно реализовать.
[оверквотинг поскипан] (ты кстати, если не отвечаешь то не цитируй простыни)
Я так понимаю что по лишним классам вопросов нет?
PE>>>А конструкторы ? AVK>>Что конструкторы?
PE>А в конструкторах по твоему методу нужно приинициализировать все инстанцы, которые заведуют оработкой событий от объекта i-ой проперти. Им нужно this сообщить.
Чего то я не понял. Инициализировать ничего не нужно. this нужен при подписке на событие. Нужен он притом в обоих вариантах, просто в случае с делегатом компилятор втыкает его неявно. Что то я не вижу тут никакой разницы.
AVK>>Так надо так строить приложение чтобы легко было имитировать внешнюю среду для отдельных блоков. Еще юнит тестирование в таких случаях рулит.
PE>Для сетевой модели сложность написания тестов O(n**2).
Сам придумал? Сложность тестов зависит не от структуры данных, а от структуры приложения. Те баги о которых шла речь к трудноулавливаемым не относятся. Кроме того я что то не пойму — а вы сейчас вобще не тестируете?
PE> Вперед !
Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.
PE>Загрузку и сохранение уже не протестируешь
Чего так? Ты ж учти — кодогенератор генерирует все одинаково. Если ты отладишь самый сложный класс, то остальные автоматом так же будут отлажены, правишь то ты генератор, а не конкретный класс. Так что в итоге задачка сводится не к отладке моря кода, который генерится, а к отладке единственного генератора.
PE> не говоря об самых маленьких алгоритмах.
А при чем тут генератор? Ручные алгоритмы надо отлаживать в любой ситуации, генеришь ты код или руками пишешь неважно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>>не могут интесеваться производительностью ПО за которое платят деньги ? AVK>>>Пользователь платит деньги за компиляторы? Это что то новенькое.
PE>>Компилятор влияет на производительность ПО.
AVK>Влияет. Только шустрики не об этом.
PE>>И не выдергивай слова из фразы.Это не к лицу модератору.
AVK>Во-первых это демагогия.
Вот моя интерпретация
"производительностью ПО за которое платят деньги"
Вот твоя
"ПО за которое платят деньги"+ "Пользователь платит деньги за компиляторы? "
PE>>Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.
AVK>Вот только шустрики не о производительности декодеров mp3.
Наконец то. А о чем ? Обо всем, что некасается этого ? Не верю !
AVK>>>>>Т.е. какие то компиляторы всегда делают тормозное глюкало? PE>>Конечно. Это в ваших шустриках и написано, что одни компилеры дают шустрый код, другие тормозной.
AVK>А про глюки там тоже написано или ты для красного словца?
Глюкало было в контексте в отношении двух подопытных. Ссылку дать ?
PE>>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++, AVK>На этот вопрос сможешь ответить только ты сам.
Этот вопрос интересует не только меня. Глядя на вашу синтетику, я могу сказать, что на синтетике дотнет немеряно крут. если вы писали синтетику ради синтетики в академических интересах — у меня вопросов нет более.
PE>>Отлично. Сделаем по твоему. Процессоры одинаковые и железо одинаковое. PE>>Осталось сравнить три продукта (нативный, дотнетовский, жавовский).
AVK>Вот и возвращаемся к исходному вопросу — нафига там тестировать алгоритмы упаковки звука, если процент программистов, на которых эта статья нацелена, занимающихся звуком весьма мал?
Отвечаю в который раз — хочется выяснить область применения дотнета. Для того и тестируют, чтобы знать, какой выбор делать.
Если ты считаешь,что программисты пишут только распределенные корпоративные системы, то глубоко заблуждаешься.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>Компилятор влияет на производительность ПО.
AVK>>Влияет. Только шустрики не об этом.
PE>>>И не выдергивай слова из фразы.Это не к лицу модератору.
AVK>>Во-первых это демагогия.
Т.е. это тот кусок к которому у тебя притензии? Ага, интересно. И что же я выкинул из цитаты?
PE>>>Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.
AVK>>Вот только шустрики не о производительности декодеров mp3.
PE>Наконец то. А о чем ? Обо всем, что некасается этого ? Не верю !
Ты наверное будешь удивлен, но о компиляторах.
PE>>>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++, AVK>>На этот вопрос сможешь ответить только ты сам. PE>Этот вопрос интересует не только меня.
А кого еще? Только не надо про пользователей.
PE> Глядя на вашу синтетику, я могу сказать, что на синтетике дотнет немеряно крут. если вы писали синтетику ради синтетики в академических интересах — у меня вопросов нет более.
Предложи алгоритмы, используемые значительной частью программистов. Программистов, заметь, не пользователей.
AVK>>Вот и возвращаемся к исходному вопросу — нафига там тестировать алгоритмы упаковки звука, если процент программистов, на которых эта статья нацелена, занимающихся звуком весьма мал?
PE>Отвечаю в который раз — хочется выяснить область применения дотнета.
Напоминаю в который раз что шустрики не об этом. Если хочешь — протестируй сам и напиши свою статью о компиляторах в обработке звука, мы ее с удовольствием опубликуем.
PE>Если ты считаешь,что программисты пишут только распределенные корпоративные системы, то глубоко заблуждаешься.
Нет конечно, но очень приличное количество их. Можешь провести опрос кто чем занимается.
Здравствуйте, AndrewVK, Вы писали:
PE>>>>А при чем здесь COM ? AVK>>>Вот и я о том же. PE>>Про COM ты сам вспомнил. AVK>Ага, и Влад тоже, синхронно со мной. А ты как бы про него даже не писал.
Я предложил реализовать механизм, аналогичный IConnectionPointContainer.
PE>> Я ничего не говорил. AVK>Цитату привести?
Давай.
AVK>>>Тогда какое это имеет отношение к замене событий интерфейсами? PE>>Это ты предложил интерфейсы и даже собственную реализацию привел.
AVK>Предложил не я. Я тебе ответил на вопрос как примерно это можно реализовать.
Вот в этой примерной реализации и были интерфейсы.
AVK>[оверквотинг поскипан] (ты кстати, если не отвечаешь то не цитируй простыни) AVK>Я так понимаю что по лишним классам вопросов нет?
PE>>>>А конструкторы ? AVK>>>Что конструкторы?
PE>>А в конструкторах по твоему методу нужно приинициализировать все инстанцы, которые заведуют оработкой событий от объекта i-ой проперти. Им нужно this сообщить.
AVK>Чего то я не понял. Инициализировать ничего не нужно. this нужен при подписке на событие. Нужен он притом в обоих вариантах, просто в случае с делегатом компилятор втыкает его неявно. Что то я не вижу тут никакой разницы.
PE>>Для сетевой модели сложность написания тестов O(n**2).
AVK>Сам придумал? Сложность тестов зависит не от структуры данных, а от структуры приложения. Те баги о которых шла речь к трудноулавливаемым не относятся.
Структура модели данных — гиперграф это и есть аппликация, если тестируешь только это. Это отдельная часть проекта.
Вот для него то сложность тестирования и равна O(n**2)
Баги, про которые я сказал, естественно не относятся к трудноулавливаемым. Но объемы тестирования очень велики.
PE>> Вперед !
AVK>Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.
Сетевая какой сложности ? Давай сравним.
PE>>Загрузку и сохранение уже не протестируешь
AVK>Чего так? Ты ж учти — кодогенератор генерирует все одинаково. Если ты отладишь самый сложный класс, то остальные автоматом так же будут отлажены, правишь то ты генератор, а не конкретный класс. Так что в итоге задачка сводится не к отладке моря кода, который генерится, а к отладке единственного генератора.
Мы именно так и делаем. Только речь шла про тесты. Каким это кодогенератором ты пртестируешь загрузку-сохранение модели ?
PE>> не говоря об самых маленьких алгоритмах.
AVK>А при чем тут генератор? Ручные алгоритмы надо отлаживать в любой ситуации, генеришь ты код или руками пишешь неважно.
Вот тут то и проблема. Для графа с количеством узлов N надо перебрать O(N**2) ситуаций для тестирования алгоритма. Если это делать отдельно от прилаги основном, то ты просто повесишься.
Сама прила берет на себя чоень многое. Тестируется все чз. винраннер и скрипты.
Версия тестируется примерно 10000...50000 часов. Баги проверяются уже на отловленых специфичных ситуациях.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Сам придумал? Сложность тестов зависит не от структуры данных, а от структуры приложения. Те баги о которых шла речь к трудноулавливаемым не относятся.
PE>Структура модели данных — гиперграф это и есть аппликация, если тестируешь только это. Это отдельная часть проекта. PE>Вот для него то сложность тестирования и равна O(n**2)
Но речь то не о тестировании гиперграфа, который при любом раскладе тестировать нужно. Речь о тестировании генератора.
AVK>>Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.
PE>Сетевая какой сложности ? Давай сравним.
Пиписьками мерятся? И в чем сложность оценивать? В численных характеристиках? Несколько десятков сущностей, до 1 млн. экземпляров.
PE>Мы именно так и делаем. Только речь шла про тесты. Каким это кодогенератором ты пртестируешь загрузку-сохранение модели ?
Речь шла о том что перенесение части ошибок в рантайм из-за использования генератора не так уж и страшна.
AVK>>А при чем тут генератор? Ручные алгоритмы надо отлаживать в любой ситуации, генеришь ты код или руками пишешь неважно.
PE>Вот тут то и проблема. Для графа с количеством узлов N надо перебрать O(N**2) ситуаций для тестирования алгоритма. Если это делать отдельно от прилаги основном, то ты просто повесишься.
А смысл? Стоимость перебора вариантов всегда очень высока. Обычно обходятся использованием стабильных и предсказуемых алгоритмов и тестирования характерных случаев.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Во-первых это демагогия.
AVK>Т.е. это тот кусок к которому у тебя притензии? Ага, интересно. И что же я выкинул из цитаты?
слово "производительность" ты оставил на верхней строчке и ответил на последнюю часть фразы без слова производительность. Это в корне меняет ситуацию.
AVK>>А причем тут пользователи? Речь о программистах.
PE>Т.е. пользователи сук и быдло
Я этого не говорил.
PE> и не могут интесеваться производительностью ПО
Может. Но шустрики не для него.
PE> за которое платят деньги ?
Пользователь платит деньги за компиляторы? Это что то новенькое.
Как из моей фразы следует утверждение "Пользователь платит деньги за компиляторы." ?
Компилятор влияет на производительность ПО за которое пользователи платят деньги.
PE>>>>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++, AVK>>>На этот вопрос сможешь ответить только ты сам. PE>>Этот вопрос интересует не только меня.
AVK>А кого еще? Только не надо про пользователей.
PE>> Глядя на вашу синтетику, я могу сказать, что на синтетике дотнет немеряно крут. если вы писали синтетику ради синтетики в академических интересах — у меня вопросов нет более.
AVK>Предложи алгоритмы, используемые значительной частью программистов. Программистов, заметь, не пользователей.
Почти все мои одногруптики раобтают на госпредприятиях. Основная часть — военка, моделирование и всякая математика. Многие работают со звком. Сжатие звука для передачи по модемным сетям хитрым. Сжатие для тел станций. Запись под диктовку, верификация и тд. Имитация шумов. Распознавание изображений(выделение номеров машин). Много чего. Достаточно ?
С БД работают очень мало.
Здравствуйте, AndrewVK, Вы писали:
PE>>Структура модели данных — гиперграф это и есть аппликация, если тестируешь только это. Это отдельная часть проекта. PE>>Вот для него то сложность тестирования и равна O(n**2)
AVK>Но речь то не о тестировании гиперграфа, который при любом раскладе тестировать нужно. Речь о тестировании генератора.
Ну протестирую я генератор колекций, и что с того ? Колекции — это пыль, их по одному шалону в ЕА создаем. Написали генератор текста(на жаве ) и все пучком.
Генерировать нужно совсем другое.
AVK>>>Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.
А новые люди сколько в этом разбираются ?
PE>>Сетевая какой сложности ? Давай сравним.
AVK>Пиписьками мерятся? И в чем сложность оценивать? В численных характеристиках? Несколько десятков сущностей, до 1 млн. экземпляров.
Если ваша с сеть однороная, то хоть миллиарды. У нас примерно 600 классов, писаных от руки.
Все классы очень сильно отличаются друг от друга. Это представление сети на разных уровнях.
Сети, сегменты, подсети, узлы, связи, волокна, траффик, пути, таблицы различные (не коллекции). Технологии, информация об оборудовании, информация о конфигурации этого оборудования. Каждый элемент должен имеет тип, имя, описание. Каждый имеет свой рисунок.
По какому принципу генерировать — непонятно. Все это описывается в соответсвующих разделах теории оптических сетей.
AVK>А смысл? Стоимость перебора вариантов всегда очень высока. Обычно обходятся использованием стабильных и предсказуемых алгоритмов и тестирования характерных случаев.
Каждый случай в графе это характерный. Если есть подозрение, что алгоритм генерирует неоптимальное решение, то очень сложно выявить ошибку. Иногда такие ошибки ищутся месяцами.
Это ты реалзовал простейший случай. В одном классе может быть несколько консумеров.
Вот во что это превращается реально. Этот вариант мы уже отрабатывали.
AVK>public class EventConsumer
AVK>{
выделенные фрагменты кода при наличии дженериков или рефлексии можно услать в базовый класс.
без дженериков или рефлексии мне нужна информация о типе
[Serialized]
class Property1EventProviderHolder : ISomeEventHandler
{
// от этого никуда не деться.public void OnChanging(object sender, ChangingEventArgs args)
{
EventProvider ep = (EventProvider)sender;
if(m_THIS.PropertyN == somevalue) args.Cancel = true;
if(...)
}
public void OnChanged(object sender, ChangedEventArgs args)
{
Do Anything
or
m_THIS.DeleteSelf();
}
public void OnDisposing(object sender, DisposingEventArgs args)
{
EventProvider ep = (EventProvider)sender;
if(m_THIS.PropertyN == somevalue) args.Cancel = true;
if(...)
}
public void OnDisposed(object sender, DisposedEventArgs args)
{
m_value = null;
or
m_THIS.DeleteSelf();
}
public void Validate(EventProvider val)
{
EventConsumer.Validators.ValidateProperty1(m_THIS, val);
}public void Set(Property1EventProviderHolder THIS, EventProvider value)
{
m_THIS = THIS;
Validate(value); // здесь бросается эксцепшн.if(value == m_value)
return;
if(propertyName == null)
throw new ArgumentNullException("Property1");
if(m_value != null)
{
m_value.RemoveSomeEventHandler(this);
if(m_bComposite)
m_value.DeleteSelf();
}
if(value != null)
value.AddSomeEventHandler(this);
value = m_value;
}
EventProvider m_value = null;
Property1EventProviderHolder THIS=null;
}
Property1EventProviderHolder m_property1;
public EventProviderHolder Property1
{
get{ return m_property1.m_value;}
set
{ m_property1.Set(this,value); }
}
}
}
После того, как ты разобрался, умножь это все на 20 — именно столько пропертей может слушаться одновременно. Еще 10 пропроще.
Если писать в одном интерфейсе аж 4 эвента, то получается классов нужно оъявлять меньше.
Но тогда будет много методов пустых.
Если интерфейсы из одного метода, то получится тоже самое, что и у нас сейчас, только кода побольше будет.
Нам удалось сделать так, что в большинстве случаев оработчики либо пустые (их вовсе нет) либо по одному-два.
Но это еще не все.
При серилизации увеличивается время — количество ссылок на оъект увеличивается примерно в три раза !
Сейчас у меня 1 пропертя — одна ссылка.
В такой схеме — m_property,m_value и обратная ссылка — 3.
При десерилизации экономится немного времени на создание делегатов. Количество объектов увеличивается в 1.5 ... 2 и из за O(n**2) десерилизации все это малозаметно. Больше двх раз не может быть — по одному на каждую пропертю.
А вот будь у меня дженерики... Десерилизация и серилизация все равно будут тормозить. Но зато количесво рефлекшна уменьшится очень сильно ! Итого — нужно писать сериалайзер.
ИТОГО: Кода в твоем случае получается поболее... C эвентами и рефлекшном нам удалось
Здравствуйте, VladD2, Вы писали:
PE>>Я думаю, что нормальный путь — выдрать сериалайзер из ротора и кой какие пместа оптимизировать. Но неясно, как это толкнуть в обиход. Это есть нарушение. PE>>А нам чу что придется написать примерно такой же форматтер.
VD>Это очень сложно. Он там на мертво врос.
Это очень просто ! Выдираешь исходники форматтера, ObjectIDGenerator, подсовываешь свои заглушки для ресурсов и кой каких фейковых классов, комментируешь дебаговую муть и юзаешь.
Здравствуйте, Plutonia Experiment, Вы писали:
PE> PE>Это очень просто ! Выдираешь исходники форматтера, ObjectIDGenerator, подсовываешь свои заглушки для ресурсов и кой каких фейковых классов, комментируешь дебаговую муть и юзаешь.
PE>Могу выслать готовый проект.
Давай. Это даже интересно.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
PE>> PE>>Это очень просто ! Выдираешь исходники форматтера, ObjectIDGenerator, подсовываешь свои заглушки для ресурсов и кой каких фейковых классов, комментируешь дебаговую муть и юзаешь.
PE>>Могу выслать готовый проект.
VD>Давай. Это даже интересно.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Т.е. это тот кусок к которому у тебя притензии? Ага, интересно. И что же я выкинул из цитаты?
PE>слово "производительность" ты оставил на верхней строчке
Блин, уписаться можно. Я уже не так отформатировал. Вобщем демагогия. Нечего сказать начинаешь придираться к тому что на какой строчке расположено.
AVK>>Предложи алгоритмы, используемые значительной частью программистов. Программистов, заметь, не пользователей.
PE>Почти все мои одногруптики раобтают на госпредприятиях.
Несчастные. А у меня наверное уже никто не работает.
PE> Основная часть — военка, моделирование и всякая математика. Многие работают со звком. Сжатие звука для передачи по модемным сетям хитрым. Сжатие для тел станций. Запись под диктовку, верификация и тд. Имитация шумов. Распознавание изображений(выделение номеров машин). Много чего. PE>Достаточно ?
Нет. Почему ты решил что твои одногрупники являются основной аудиторией сайта и журнала?
Здравствуйте, Plutonia Experiment, Вы писали:
PE> [Serialized]
Serializable?
PE> class Property1EventProviderHolder : ISomeEventHandler
Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс?
PE>После того, как ты разобрался, умножь это все на 20 — именно столько пропертей может слушаться одновременно. Еще 10 пропроще.
Не, ну до маразма что угодно можно довести.
PE>Если писать в одном интерфейсе аж 4 эвента, то получается классов нужно оъявлять меньше.
Зачем? Ты опять чего то не понял. 1 интерфейс = 1 тип эвента. Если класс подписывается на несколько разных типов эвентов он реализует несколько интерфейсов.
PE>Если интерфейсы из одного метода, то получится тоже самое, что и у нас сейчас, только кода побольше будет.
О том и речь.
PE>ИТОГО: Кода в твоем случае получается поболее...
Побольше, в основном в источнике события, а вот в потребителе даже поменьше получается.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Ну протестирую я генератор колекций, и что с того ?
То что генеренный код после этого при изменении входных данных особо тестировать не надо.
AVK>>>>Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.
PE>А новые люди сколько в этом разбираются ?
Нету у нас таких.
AVK>>Пиписьками мерятся? И в чем сложность оценивать? В численных характеристиках? Несколько десятков сущностей, до 1 млн. экземпляров.
PE>Если ваша с сеть однороная, то хоть миллиарды.
Я же написал — несколько десятков сущностей. Какая она однородная? Связи тоже нескольких типов.
Да, естественно ни о какой автоматической сериализации я даже не думал. Запись целиком собственная, в БД, с кешированием и сериализацией только измененных частей. Иначе это при любом варианте автоматической тормоза. А мне надо чтобы сохранение изменений занимало не более 1-2 секунд.
PE> У нас примерно 600 классов, писаных от руки.
Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.
PE>По какому принципу генерировать — непонятно.
Принцип очень простой. Как бы они ни были неоднородны, если ты их обрабатываешь где то по одинаковым правилам (ну сериализуешь к примеру), значит что то общее в них есть. Вот тебе и основа для генератора.
PE>Каждый случай в графе это характерный. Если есть подозрение, что алгоритм генерирует неоптимальное решение, то очень сложно выявить ошибку. Иногда такие ошибки ищутся месяцами.
ИМХО это сигнал для серьезного пересмотра дизайна программы.
Здравствуйте, AndrewVK, Вы писали:
PE>> Основная часть — военка, моделирование и всякая математика. Многие работают со звком. Сжатие звука для передачи по модемным сетям хитрым. Сжатие для тел станций. Запись под диктовку, верификация и тд. Имитация шумов. Распознавание изображений(выделение номеров машин). Много чего. PE>>Достаточно ?
AVK>Нет. Почему ты решил что твои одногрупники являются основной аудиторией сайта и журнала?
К сайту и журналу они никакого отношения не имеют. У троих только инет есть.
А журнал в Минске... лучше изредка оффлайновые версии посматривать.
Здравствуйте, AndrewVK, Вы писали:
PE>> [Serialized] AVK>Serializable?
Да.
PE>> class Property1EventProviderHolder : ISomeEventHandler
AVK>Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс?
А как по другому ? Объект одновременно и подписчик десятков эвентов и консумер стольких.
А еще есть эвенты от коллекций например.
PE>>После того, как ты разобрался, умножь это все на 20 — именно столько пропертей может слушаться одновременно. Еще 10 пропроще.
AVK>Не, ну до маразма что угодно можно довести.
Сложность задачи определяет кастомер, а не мы.
Конечно, с твоей точки зрения это маразм, потому что ты не представляешь модели оптической сети. Заказчики наши это не рядовые предприятия и тд. Это отдельные государства, крупные корпорации. Для такого мастшаба требуется гораздо сложнее модель, чем у нас.
Мы лишь упростили максимально. Но в люом случае сложность очень высокая.
PE>>Если интерфейсы из одного метода, то получится тоже самое, что и у нас сейчас, только кода побольше будет. AVK>О том и речь.
Так а зачем лишний код ? Нам и так пролему приходится решать с нынешним количесвом.
PE>>ИТОГО: Кода в твоем случае получается поболее... AVK>Побольше, в основном в источнике события, а вот в потребителе даже поменьше получается.
Вот что я прикинул на счет ссылок и объектов(вчера я неправильно оценил). Если вводить один объект на пропертю, количество объектов для серелизации увеличится на количество пропертей. Сериалайзер этого не вынесет. И десериалайзер тоже.
Количество ссылок удваивается — опят же геморрой. Будет ли быстрее работать алгоритм — сложный вопрос. Кое где экономия есть, но цепочки взаимодействия длинне.
И если один слой мадели будет сохряняться десятки минут — это все геморрой.
Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой.
Над этим работаем.