Re: [Collections] Suppliers, Iterables, and Producers

2024-04-28 Thread Brett Okken
> There is no primitive specialisation of Iterator for long https://docs.oracle.com/javase/8/docs/api/java/util/PrimitiveIterator.OfLong.html On Sun, Apr 28, 2024 at 10:00 AM Alex Herbert wrote: > Hi Gary, > > I am in favour of using nomenclature and patterns that will be familiar to > a

Re: [math] working on increasing performance for Math3

2021-05-10 Thread Brett Okken
The explicit cast to primitive does not result in boxing/unboxing. It is the "magic" of PolymorphicSignature which actually adjusts to allow for primitives. On Mon, May 10, 2021 at 11:08 AM Erik Svensson wrote: > > > On 2021-05-10, 18:03, "Brett Okken" wrote: >

Re: [math] working on increasing performance for Math3

2021-05-10 Thread Brett Okken
Perhaps it is an Intellij issue. The MethodHandle javadoc[1] has an "Usage examples" section. One of the examples shows calling List.size() (which returns an int): > Object x, y; String s; int i; > MethodType mt; MethodHandle mh; > MethodHandles.Lookup lookup = MethodHandles.lookup(); > ... > mt

Re: [math] working on increasing performance for Math3

2021-05-10 Thread Brett Okken
> Secondly, MethodHandle.invokeExact() takes and returns an object so there's a > boxing/unboxing involved as well (as the Math/FastMath methods returns > primitives). There is "magic" going on here that actually avoids boxing. You can/should cast directly to the primitive type. That is what

Re: [math] working on increasing performance for Math3

2021-05-10 Thread Brett Okken
Out of curiosity, what specifically about MethodHandles use consumed the time? Was it the discovery/initialization or the steady-state usage? My observation has been that if the MH itself is static final and invokeExact is used, performance at steady-state is identical to making the call

Re: make gzip deflate buffer size configurable

2021-02-19 Thread Brett Okken
https://issues.apache.org/jira/browse/COMPRESS-566 https://github.com/apache/commons-compress/pull/168 Thanks, Brett On Wed, Feb 17, 2021 at 1:23 PM Gary Gregory wrote: > > Yes in both cases is safest. > > Gary > > On Wed, Feb 17, 2021, 14:17 Brett Okken wrote: > > &

Re: make gzip deflate buffer size configurable

2021-02-17 Thread Brett Okken
Gregory wrote: > > Sounds good to me. Also the default seems small, or is that a standard size > for Gzip, otherwise 4k or 8k seems better. > > Gary > > > On Wed, Feb 17, 2021, 11:48 Brett Okken wrote: > > > The deflateBuffer in GzipCompressorOutputStream is ha

make gzip deflate buffer size configurable

2021-02-17 Thread Brett Okken
The deflateBuffer in GzipCompressorOutputStream is hardcoded to 512. Are there any objections to making that size configurable in GzipParameters? If that is acceptable, I can create a PR with the changes. Thanks, Brett - To