Re: Response to LC-2706

Hi Daniel,

I acknowledge the possibilities that the EXI profile provides to adjust
the runtime memory usage and tune the processing according to particular
documents.
As you said the tuning is highly dependent on the used options and even
more on the used test set. What I argue is that there is no straight
forward way to guess or predict what are the values for the parameters
for optimal performance or a predefined memory limit given a particular
test set. Note that often there is no a predefined test set - at least
the string values in the documents will likely vary - making the proper
use of localValuePartitions and valuePartitionCapacity doubtful.
Most users will not have a clue to what this parameters stands for. They
will test the Profile with the default parameters, that is plain EXI,
and see that it does not make any difference in terms memory, code size
etc. 

This unpredictability is what makes me cautions about the
specification. 

Best Regards,
Rumen Kyusakov

On Thu, 2012-11-15 at 09:05 +0100, Peintner, Daniel (ext) wrote:
> Hi Rumen,
> 
> Thank you very much for your feedback. Please find our comments inline.
> 
> > Subject: Evaluations of EXI in application areas with memory
> > restrictions
> > Section: 1. Introduction
> > Paragraph: "Certain evaluations of EXI in the context of such areas..."
> > Comments:
> > It is good to have access to these evaluations.
> 
> We found that EXI is difficult to deploy on restricted devices (e.g., microcontrollers). Therefore we were focusing on constraints that on the one hand keep compatibility with EXI 1.0 and on the other hand support easy deployment on restricted devices. To better reflect this fact we updated the draft using the word "findings" instead of "evaluations".
> 
> >  From my own perspective and use cases this profile will not bring
> > much benefits. I am working with very small messages over
> > low-bandwidth wireless links (up to 250 kb/s). Of course, memory
> > is an issue but the compression is even more important.
> 
> I would like to note that the EXI profile is very beneficial for device classes that cannot afford memory allocation at runtime and also need to deal with built-in element grammars. The profile makes it possible to account for the required memory at compile time which was not possible in EXI 1.0 before.
> Further, the possibility of using global value string tables only (setting localValuePartitions to FALSE) reduces the code footprint on restricted devices and still provides a very good solution for documents containing lots of strings.
> 
> > It would be good to have some statistics on what are the trade-offs
> > (memory usage vs compression) by using the Profile in different
> > use-cases (size and structure of the messages).
> 
> The EXI profile may not have any effect on some EXI streams while at the same time reducing code footprint and memory usage. Unfortunately we are not yet able to provide any statistics or make any statement about memory usage vs. compression. These statistics highly depend on the used options and even more on the used test set (e.g., ratio between data encoded with schema-informed grammars vs. data encoded with built-in element grammars).
> 
> We hope that makes you understand our reasoning,
> 
> -- Daniel

Received on Monday, 19 November 2012 09:37:11 UTC