Use Advanced Search to search the entire archive.
[jsr363-experts] Re: Contradiction between the spec and javadoc
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: Contradiction between the spec and javadoc
- Date: Tue, 16 Dec 2014 12:07:05 +0100
I already added a sentence related to "convenience" from a developer's
point of view just above that. If you really think performance deserves a
separate chapter (a few EC members probably are quite keen on that,
especially those from companies that make a living from VM tweaks or
performance optimization;-D) why not, but I would certainly not let the EDR
deadline slip now and submit it to PMO later than tomorrow.
We could add more chapters later.
Werner
On Tue, Dec 16, 2014 at 11:13 AM, Martin Desruisseaux <
>
wrote:
>
>
Le 16/12/14 19:06, Leonardo Lima a écrit :
>
>
"*no runtime overhead compared with an implementation not using Unit-API"
>
*is impossible to reach, I don't see how an implementation using objects
>
will be faster than one using only primitives (unless primitives started
>
being Objects in ME 8 and I didn't notice...).
>
>
So I believe that when using the API, we're trading a little performance
>
for a clear, less bug-prone code.
>
>
I think we need to at least change this goal to be "the smallest
>
possible overhead...", if such wording is allowed in a spec.
>
>
>
Actually I think that the performance question deserve a small chapter on
>
its own. I have removed this sentence for now and will create a JIRA task
>
for what I think should be in a performance chapter. The chapter would
>
discuss two or three different ways to handle measurement in JSR-363:
>
>
>
- Using Quantity objects: easier, but high memory and performance
>
cost. Best suited for metadata object I think.
>
- Using double[] + Unit, and developer use UnitConversion himself.
>
Better suited for time series (or any data where lot of values have the
>
same unit).
>
>
>
The convenience / performance tradeoff of those different approaches would
>
be discussed, so developers can choose the one the prefer.
>
>
Martin
>
>