веб, ASP, начало

[OmegaBerkut]

Пепел Феникса
Неправильно то, что сервер занимается обработкой и отправкой дубликата иформации. Как я уже сказал - отправили необработанный текст, сервер сохранил, и ... всё. Сервер может отправить информацию о том, что данные получены. Остальное на стороне пользователя.

Что касательно рекурсии: за нас будет хранить стек потока - именно к этому я и веду; не нужно тратить время на постройку целой структуры, когда есть логика управления, о чём я уже и говорил. А позиция строки - это одно число; пачка ранее открытых тегов - кол-во памяти будет расти в зависимости от ... количества ранее открытых тегов.

[Alex11223]

Так сервер в любом случае умеет обрабатывать, как минимум для мамонтов из 2000 года или параноиков без JS, движок же не молодой. Тогда пришлось бы дублировать этот код + иметь риск получить разный результат при обработке сервером и клиентом

[Пепел Феникса]

Неправильно то, что сервер занимается обработкой и отправкой дубликата иформации. Как я уже сказал - отправили необработанный текст, сервер сохранил, и ... всё.

существует баланс между удобством и производительностью сервера.
сообщения можно отдавать как сырые, но вот нюанс, а выключите JS? что тогда?
форум рассчитан на это.
да и если слишком много вычислений делать на клиенте, клиент начинает тормозить, тут тоже не все так просто.(хотя тот мой проект-БД работает именно на таком принципе, но сайт не может работать без JS)

то касательно рекурсии: за нас будет хранить стек потока - именно к этому я и веду; не нужно тратить время на постройку целой структуры, когда есть логика управления, о чём я уже и говорил.

у вас проблемы с применением простого списка?

А позиция строки - это одно число; пачка ранее открытых тегов - кол-во памяти будет расти в зависимости от ... количества ранее открытых тегов.

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

[OmegaBerkut]

Сообщение от Alex11223

иметь риск получить разный результат при обработке сервером и клиентом

Это если погромист ошибся в написании алгоритма для пользовательской обработки. В любом случае, кто сервер тот и прав. А сервер может как обрабатывать информацию перед отправкой, так и просто выбросить необработанную информацию, и пускай обработкой занимается юзверь. Всё равно браузер так или иначе парсит получаемый HTML. А при такой логике сервер сможет уделить больше времени на обработку запросов, а значит - одновременно обработать больше ВНЕЗАПНО запросов.

Пепел Феникса
Нет, проблем при работе со списком нет. Но при работе с рекурсией не нужно руками хранить эту информацию. А размер стека можно и увеличить. Опять же - одно число.

[Пепел Феникса]

а значит - одновременно обработать больше ВНЕЗАПНО запросов.

я вас огорчу, вряд-ли, парсинг сообщения это чуть ли не самая меньшая статья расходов
даже для больших сообщений.

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

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

вы сами не чувствуете что подписываетесь на какую-то Ж?

[OmegaBerkut]

Пепел Феникса
Парсинг - это только конкретный пример. Я больше чем уверен, что таких примеров навалом, даже для одного сайта. А если пользователь затормозит чуть больше, чем на секунду - сервер сможет за это время обработать ещё запросов.

[Alex11223]

Сообщение от OmegaBerkut

А при твкой логике сервер сможет уделить больше времени на обработку запросов, а значит - одновременно обработать больше ВНЕЗАПНО запросов.

Да ему и так норм

Сообщение от OmegaBerkut

Это если погромист ошибся в написании алгоритма для пользовательской обработки.

ну так чем больше кода, тем вероятнее ошибка.
И еще придется обновлять если вдруг сервер решит что-то изменить в обработке.

[Пепел Феникса]

А если пользователь затормозит чуть больше, чем на секунду - сервер сможет за это время обработать ещё запросов.

а причем тут торможение пользователя?
сервер не ждет ничего итак.

Парсинг - это только конкретный пример.

а это по сути большее что вы и сказали, вы убираете тысячные процента нагрузки на сервер, ради повышения нагрузки на клиента.(причем нагрузка на клиента растет больше).
любое формирование контента на клиенте вызывает торможение у него.(и JS клиента работает медленее чем сервер)
итого, у нас сайт долго открывается, клиенты уходят.
но зато мы смогли обработать на один запрос в минуту больше(причем в пике, который еще достигнуть надо), браво

PS: я обновил ответ добавив часть про стек.

[OmegaBerkut]

Пепел Феникса
Размер стека можно задавать программно. Даже при подсчёте макс. уровня вложения не придётся хранить информацию о самих тегах.
Мы подошли к выбору баланса при оптимизации между CPU и RAM.

[Пепел Феникса]

Размер стека можно задавать программно.

можно пример, как его изменить?(во время выполнения прям, не при создании потока)
ни разу не встречал.

+ на стек существуют лимиты сверху.

Мы подошли к выбору баланса при оптимизации между CPU и RAM.

ээ...для справки, стек это тоже RAM.

Даже при подсчёте макс. уровня вложения не придётся хранить информацию о самих тегах.

а куда денется то текущий элемент из стека процесса?(я имею в виду во всей линии рекурсивности)

и да, еще для справки в дотнете StackOverflowException является фатальным, и его нельзя поймать, как обрабатывать то будете?