Здравствуйте, Ночной Смотрящий, Вы писали:

S>>Ок, поправлюсь: огласите, пожалуйста, свое видение данного вопроса. Почему мое ошибочно?
НС>Неуважение твое заключается не в том что ты пожалуйста не написал, а в том что я тебе прямо написал почему сделано так, но ты то ли не читаешь, то ли с памятью у тебя серьезные проблемы.

Дайте ссылку на объяснение, ибо я ничего такого не помню.

S>>Какие же фантазии, когда мы тут видим цепочки наследования в wpf.
НС>Я тебе показал как МС решила описанную тобой задачу с чекбоксами в гриде. Цепочки наследования внутри фреймворка это отдельная история не особо на дизайн прикладных решений влияющая.

Надо понять, за счет чего такое решение работает. То, что там все разбито на компоненты,
которые легко заменить или кастомизировать, говорит, что с наследованием там все впорядке. Иначе
не было бы такой легкой заменяемости. Т.е. цепочки наследования как раз причем.



S>>Важно, ибо, скорее всего, чтобы была такая гибкость, такая огромная цепочка наследования и должна быть.
НС>Попробуй доказать сие предположение.

Эт сложно. Но есть ощущение, подкрепляемое эмпирическими наблюдениями, что чем проще как-то кастомизировать
какой-либо компонент, тем длиннее у него цепочка наследований.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Так у меня, поди, и комп в три раза медленнее. Важны не абсолютные числа, а относительные.

Абсолютные тоже важны, если они очень странные.
Так почему он у тебя в три раза медленнее?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>С внимательностью у меня все отлично. Я цитату привел. Ты это прочел, а потом вдруг через несколько сообщений решил прицепиться к словам.

А, женская логика. Все, что не было оспорено немедленно, считается принятым (С)

Здравствуйте, Codealot, Вы писали:

C>Абсолютные тоже важны, если они очень странные.

Забудь про них, ориентируйся на собственные. Результат это не меняет — switch ничуть не медленее виртуальных методов.

C>Так почему он у тебя в три раза медленнее?

Потому что железо другое.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Забудь про них, ориентируйся на собственные. Результат это не меняет — switch ничуть не медленее виртуальных методов.

Медленнее, хотя не радикально.

НС>Потому что железо другое.

Это не ответ. Специально проверил бенчмарк процессоров — твой должен быть медленнее только наполовину.

Здравствуйте, Sinclair, Вы писали:

S>Допустим, вы хотите построить парсер некоторого DSL. Работать он будет, понятное дело, поверх некоторого StreamReader — хочется сделать его потоковым, и не зависеть от наличия в памяти всего разбираемого текста.

Твой DSL реально занимает гигабайты прамяти, или ты просто ищешь проблемы себе на кое какое место?

Здравствуйте, Codealot, Вы писали:
C>Твой DSL реально занимает гигабайты прамяти, или ты просто ищешь проблемы себе на кое какое место?
Нет, у меня просто аллергия на заведомо неудачные решения.

Здравствуйте, Sinclair, Вы писали:

S>Нет, у меня просто аллергия на заведомо неудачные решения.

А решение сэкономить микроскопическое количество памяти, чтобы поиметь кучу лишних проблем и просадить скорость на порядок — оно видимо очень удачное?

Здравствуйте, Codealot, Вы писали:

C>А решение сэкономить микроскопическое количество памяти, чтобы поиметь кучу лишних проблем и просадить скорость на порядок — оно видимо очень удачное?
Скорость чего вы там собрались просаживать на порядок?
А рассуждения про "микроскопическое количество" вообще выглядят очень странно.
Речь идёт об асимптотике — O(logN) против O(N).
Язык на то и язык, что на нём бывает сложно заранее ограничить объём текста.

Здравствуйте, Sinclair, Вы писали:

S>Скорость чего вы там собрались просаживать на порядок?

Не я, а ты. Скорость парсинга, естественно. Ты ведь надеюсь не думаешь, что все твои добавочные абстракции будут стоить так же дешево, как чтение символа из строки?

S>Язык на то и язык, что на нём бывает сложно заранее ограничить объём текста.

Ограничить объем прочитанного текста вообще не проблема, даже школьник должен справиться. Или тебе реально надо обрабатывать текст DSL на многие гигабайты? Я думаю, вряд ли.

Здравствуйте, Codealot, Вы писали:

C>Не я, а ты. Скорость парсинга, естественно. Ты ведь надеюсь не думаешь, что все твои добавочные абстракции будут стоить так же дешево, как чтение символа из строки?
Возьмётесь навскидку оценить стоимость "добавочных абстракций" в данном случае? Или опять будет как про сравнение switch с виртуальным вызовом?

C>Ограничить объем прочитанного текста вообще не проблема, даже школьник должен справиться. Или тебе реально надо обрабатывать текст DSL на многие гигабайты? Я думаю, вряд ли.

Здравствуйте, Sinclair, Вы писали:

S> Возьмётесь навскидку оценить стоимость "добавочных абстракций" в данном случае?

Я уже оценил.
А ты сам не в состоянии оценить разницу между чтением символа из строки по его позиции, и иерархии из пары слоев абстракции со своими буферами и кучей добавочной логики?

S> Или опять будет как про сравнение switch с виртуальным вызовом?

А что тебя не устраивает?

S>

Слишком сложно?

Здравствуйте, Codealot, Вы писали:

C>Я уже оценил.
C>А ты сам не в состоянии оценить разницу между чтением символа из строки по его позиции, и иерархии из пары слоев абстракции со своими буферами и кучей добавочной логики?
Неа, у меня квалификации не хватает. Так, на глаз — разница будет пренебрежимо малой. Особенно если учесть стоимость самого парсинга. Иметь алгоритм, который на типичных объёмах кода будет работать за 2мс вместо 6ти, но падать на файле длиннее 2GB — ну, такое себе решение.


S>> Или опять будет как про сравнение switch с виртуальным вызовом?

C>А что тебя не устраивает?
C>Слишком сложно?
То что разница в пределах статпогрешности объявлятся существенной.

Здравствуйте, Sinclair, Вы писали:

S>Так, на глаз — разница будет пренебрежимо малой.

Ну тогда проверь глаза, потому что разница между чтением строки в памяти и StreamReader будет раз в 10 даже на предельно простом линейном чтении.
Кстати, а как ты вообще собрался реализовывать бактрекинг поверх ридера?

S>падать на файле длиннее 2GB

То есть ты таки настаиваешь, что тебе надо работать с DSL-ами в гигабайты размером?

S>То что разница в пределах статпогрешности объявлятся существенной.

Ты упустил самый главный момент — само по себе значение выглядит крайне странно, учитывая сравнительную скорость процессоров по универсальному бенчмарку.

Здравствуйте, Codealot, Вы писали:

C>Ну тогда проверь глаза, потому что разница между чтением строки в памяти и StreamReader будет раз в 10 даже на предельно простом линейном чтении.
C>Кстати, а как ты вообще собрался реализовывать бактрекинг поверх ридера?
Аккуратно

C>То есть ты таки настаиваешь, что тебе надо работать с DSL-ами в гигабайты размером?
Я настаиваю на том, что в требованиях не было ограничения на размер файлов. А также не было ограничения "работать только в однопользовательской среде".
Может быть, у меня данные едут по интернету, и я хочу, не забивая RAM на кэширование, уметь разбирать и обрабатывать их по мере поступления.

C>Ты упустил самый главный момент — само по себе значение выглядит крайне странно, учитывая сравнительную скорость процессоров по универсальному бенчмарку.
Не, не упустил. Ваше непонимание того, что "универсальный бенчмарк" измеряет быстродействие некоторой нагрузки, которая состоит из смеси разных команд, я отметил.
Но не счёл его заслуживающим отдельного ответа.

Здравствуйте, Sinclair, Вы писали:

S>Аккуратно

Это не ответ. Рассказывай. А то мне кажется, что ни малейшей идеи как это сделать у тебя нет.

S>Я настаиваю на том, что в требованиях не было ограничения на размер файлов. А также не было ограничения "работать только в однопользовательской среде".
S>Может быть, у меня данные едут по интернету, и я хочу, не забивая RAM на кэширование, уметь разбирать и обрабатывать их по мере поступления.

То есть ты настаиваешь на том, что память тебе крайне дорога, а вот на процессор тебе плевать.

S>"универсальный бенчмарк" измеряет быстродействие некоторой нагрузки, которая состоит из смеси разных команд, я отметил.

И что? С чего бы данной конкретной задаче настолько отличаться от смеси?
Впрочем, это все неважно. Кто-то там писал, что vtable — это дорого, и можно быстрее. Так что я все еще жду ответов, чем его можно заменить. Вариант "не знаю, зато у меня есть замена рефлекшену в некоторых случаях" не принимается.

Здравствуйте, Sinclair, Вы писали:

C>>А решение сэкономить микроскопическое количество памяти, чтобы поиметь кучу лишних проблем и просадить скорость на порядок — оно видимо очень удачное?
S>Скорость чего вы там собрались просаживать на порядок?
S>А рассуждения про "микроскопическое количество" вообще выглядят очень странно.
S>Речь идёт об асимптотике — O(logN) против O(N).

Где в этой задаче возникает такая асимптотика? Это про парсер?

Здравствуйте, Sharov, Вы писали:

S>Где в этой задаче возникает такая асимптотика? Это про парсер?
Асимптотика расхода памяти. При разборе несложного формата расход памяти ~ глубине стека разбора.

Здравствуйте, Sinclair, Вы писали:

S>>Где в этой задаче возникает такая асимптотика? Это про парсер?
S>Асимптотика расхода памяти. При разборе несложного формата расход памяти ~ глубине стека разбора.

А из-за чего такая разница, то от чего мы наследуемся как-то влияет? TextReader vs StreamReader?

Здравствуйте, Sharov, Вы писали:
S>А из-за чего такая разница, то от чего мы наследуемся как-то влияет? TextReader vs StreamReader?
Нет, схема наследования не влияет. Рассуждения об асимптотике здесь только для того, чтобы как-то обосновать выбор TextReader вместо "просто строки".
Если мы выбираем "просто строку", то обязанность следить за номером строки/символа возлагается на сам парсер, и никого ни от кого наследовать не нужно.

Можно придумать и более простой пример, который будет меньше отвлекать внимание от основной задачи.