В любом случае, для скриптования — решение так себе. Одно дело — набор маленьких скриптов, другое дело — набор многомегабайтных болванок. На время запуска размер тоже влияет, так как увеличивается количество данных для считывания и загрузки.
Я не уверен, что оно так уж подходит для быстрого запуска маленьких программ. Так как минимальный размер исполнимого файла, который он создаёт, довольно велик.
джава не способна решить проблемы скриптования никак
С точки зрения потенциальных возможностей, нет никаких ограничений, чтобы эффективно использовать Java для маленьких быстрозапускающихся программ. Для этого всего лишь нужна виртуальная машина, нацеленная на быстрый запуск, а не на продолжительное оптимизированное исполнение. Большой нужды в этом нет, потому что Java — это не скриптовый язык. Тем не менее, список виртуальных машин Java так велик, что, вполне возможно, есть реализации, соответствующие этому требованию.
Понятно, вначале я был невнимателен и не заметил, что оценивается размер одного ответа в зависимости от количества запрашиваемых параметров, а не все необходимые данные, включая запрос.
В своё время мне довелось создавать систему обработки батареек и я задумал сделать их самоописываемыми, чтобы легко поддерживать разные типы и их версии. Особенность была в том, что требовался протокол с минимальными накладными расходами, чтобы влезть в узкий канал данных. Не найдя быстро ничего подходящего, я решил создать своё решение, и теперь вижу, что оно получилось действительно экономным.
Если для чтения одного параметра в DLMS требуется out(12 + 11) + in(12 + 2 + 4) = 41 байт, то в моём решении в минимальном варианте требовалось out(1) + in(1 + 4) = 6 байт. Ответ для пакета данных из 30 параметров мог составлять (1 + 30 * 4 = 121) байт, если все параметры лежали в одной структуре или (15 + 15 * 2 + 30 * 4 = 165) байт, если — в разрозненных.
Понятно. Осталось понять, как получается около 200 байт на 30 значений. Если данные считываются через запрос-ответ, то согласно формулам для DLMS на 30 значений уйдёт (12 + 11 * 1) * 30 + (12 + 6 * 1) * 30 = 1230 байт. Если же предположить, что запросом мы подписываемся на получение новых значений, то тогда понадобится (12 + 11 * 1) * 1 + (12 + 6 * 1) * 30 = 563 байт. И только если мы каким-то одним хитрым запросом запросили сразу 30 значений, которые придут пачкой, то выйдет (12 + 11 * 1) * 1 + (12 + 6 * 30) * 1 = 215 байт. Последний вариант выглядит странно, если нужно получить серию измерений от одного датчика, поэтому у меня возник вопрос о схеме получения данных.
Что-то никак не могу сообразить схему получения данных, которая использовалась для расчётов таблиц. Объясните, пожалуйста, как для DLMS при размере запроса — 12 + 11*n и размере ответа — 12+ 6*n получается около 200 байт на 30 полученных значений, то есть, чуть больше 6 байт на значение? Значения идут пачкой? И почему размер запроса согласно формуле больше, чем ответ?
В своё время мне довелось создавать систему обработки батареек и я задумал сделать их самоописываемыми, чтобы легко поддерживать разные типы и их версии. Особенность была в том, что требовался протокол с минимальными накладными расходами, чтобы влезть в узкий канал данных. Не найдя быстро ничего подходящего, я решил создать своё решение, и теперь вижу, что оно получилось действительно экономным.
Если для чтения одного параметра в DLMS требуется out(12 + 11) + in(12 + 2 + 4) = 41 байт, то в моём решении в минимальном варианте требовалось out(1) + in(1 + 4) = 6 байт. Ответ для пакета данных из 30 параметров мог составлять (1 + 30 * 4 = 121) байт, если все параметры лежали в одной структуре или (15 + 15 * 2 + 30 * 4 = 165) байт, если — в разрозненных.