Основной вопрос тут такой: есть ли свободная память для временного буфера? Если есть, то, по большому счету нет разницы - складывать куда-то и потом парсить или наоборот.
Парсинг "на лету" выгодней по памяти в том случае, когда может придти много символов, которые не являются данными. Например - скобки, запятые, пробелы, переводы строк в Pretty JSON. В этом случае мы их обрабатываем, но не храним.
В случае отсутствия гарантии целостности данных, подлежащих парсингу, более разумным видится прием блока целиком, проверки контрольной суммы, временной на стороне передатчика и последующей обработки. В противном случае парсинг некорректных данных может привести к бессмысленному оверхеду по ресурсам.
В противном случае парсинг некорректных данных может привести к бессмысленному оверхеду по ресурсам.
Вряд ли.
В первом случае парсинг занимает дополнительное время уже после приема строки (при том, что определить факт целостности данных мы все равно можем лишь после приема и обработки последнего символа и, собственно, контрольной суммы), а во втором - этот же парсинг происходит в процессе приема и дополнительного времени не занимает.
Т.е. второй вариант предпочтительнее как по расходу памяти, так и по времени отклика.
Почему вряд ли? Зависит от интерпретации данных. Может там нужно память резервировать - 300 байт по значку {. Задупились значки - всю память исчерпал в результате парсинга на лету.
Или, к примеру, при парсинге вычисления математические делаем в рекурсивной функции. Пока данные корректны - МК отрабатывает без проблем. Попались битые - стек сорвало.
Мало ли бывает проблем из-за неправильной интерпретации. Какой смысл, в этом случае, пыжится с "онлайн"-парсингом, ошибки обрабатывать дополнительно? Быстрее принять все и отбросить исходные данные при отсутствии их целостности.
Нет, давайте все-таки различать между собой два случая:
- парсинг текста,
- парсинг + выполнение каких-либо действий.
Естественно, мною имелся в виду исключительно первый вариант. Во втором (например, выполнение команд) у нас при совершении недостоверных действий могут быть самые разрушительные последствия. Причем, не только на стек.
Парсинг ради парсинга, т.е. поиск частей потока данных - задача, конечно, интересная, но в академическом смысле. На практике я встречался исключительно с необходимостью использования данных парсинга, т.е. преобразованных из потока символов в структуры данных - сущности JSON, числа с плавающей точкой и пр. В любом случае подразумевалась некоторая обработка/интерпретация.
Мысль-то я основную понял -на медленном канале связи остаётся время для разбора строки и процесс достижения цели немного ускоряется. Но в нем всегда есть подводные камни.
Основной вопрос тут такой: есть ли свободная память для временного буфера? Если есть, то, по большому счету нет разницы - складывать куда-то и потом парсить или наоборот.
Парсинг "на лету" выгодней по памяти в том случае, когда может придти много символов, которые не являются данными. Например - скобки, запятые, пробелы, переводы строк в Pretty JSON. В этом случае мы их обрабатываем, но не храним.
В случае отсутствия гарантии целостности данных, подлежащих парсингу, более разумным видится прием блока целиком, проверки контрольной суммы, временной на стороне передатчика и последующей обработки. В противном случае парсинг некорректных данных может привести к бессмысленному оверхеду по ресурсам.
Вряд ли.
В первом случае парсинг занимает дополнительное время уже после приема строки (при том, что определить факт целостности данных мы все равно можем лишь после приема и обработки последнего символа и, собственно, контрольной суммы), а во втором - этот же парсинг происходит в процессе приема и дополнительного времени не занимает.
Т.е. второй вариант предпочтительнее как по расходу памяти, так и по времени отклика.
Почему вряд ли? Зависит от интерпретации данных. Может там нужно память резервировать - 300 байт по значку {. Задупились значки - всю память исчерпал в результате парсинга на лету.
Или, к примеру, при парсинге вычисления математические делаем в рекурсивной функции. Пока данные корректны - МК отрабатывает без проблем. Попались битые - стек сорвало.
Мало ли бывает проблем из-за неправильной интерпретации. Какой смысл, в этом случае, пыжится с "онлайн"-парсингом, ошибки обрабатывать дополнительно? Быстрее принять все и отбросить исходные данные при отсутствии их целостности.
Нет, давайте все-таки различать между собой два случая:
- парсинг текста,
- парсинг + выполнение каких-либо действий.
Естественно, мною имелся в виду исключительно первый вариант. Во втором (например, выполнение команд) у нас при совершении недостоверных действий могут быть самые разрушительные последствия. Причем, не только на стек.
Давайте различать.
Парсинг ради парсинга, т.е. поиск частей потока данных - задача, конечно, интересная, но в академическом смысле. На практике я встречался исключительно с необходимостью использования данных парсинга, т.е. преобразованных из потока символов в структуры данных - сущности JSON, числа с плавающей точкой и пр. В любом случае подразумевалась некоторая обработка/интерпретация.
Мысль-то я основную понял -на медленном канале связи остаётся время для разбора строки и процесс достижения цели немного ускоряется. Но в нем всегда есть подводные камни.