Re: RFC: Make new versions of pgjdbc Java8+

Hello Alvaro,

On 2017-04-03 21:53, Álvaro Hernández Tortosa wrote:
> On 03/04/17 20:47, Daniel Migowski wrote:
>
>> Hello Alvaro,
>>
>> while the biggest performance hit currently in the driver is the
>> switch to java.util.Logging (i will come up with numbers regarding
>> that in a few days, comparing it to previous versions). Currently,
>> and comparing to the 9.3 driver with the current driver, the
>> Hibernate databases checks take twice the time than before! Even if
>> some parts have improved (see changes in PGStream and
>> VisibleBufferedInputStream, nice reuse of arrays there since 9.3)
>> other things have changed to the bad.
>>
>> I also already did my tests regarding the stuff below, and concluded
>> that in our company lambda’s are useful in the GUI, but as I said
>> shouldn’t be used on the server. In my tests they were about 50%
>> percent slower in the long run.
>>
>> Streams are the same thing… just look at the stack traces! Good
>> for rarely used stuff, but honestly I prefer a nice loop where you
>> see what is happening in terms of object creation over streams that
>> might be concise, but are not needed. At least not for something you
>> call potentially 100ths of times a second.
>
> While I agree Lambdas and Streams should be used with care, I'm
> still unconvinced that they really take a hit in performance (if the
> compiler is not optimizing that, which most of the time does). I would
> really love to see some numbers to prove my wrong in this respect. But
> I don't see much trends towards not using them in the Java world (but
> the contrary) and I talk to very performance conscious people.

I've remembered about this writing:
http://blog.takipi.com/benchmark-how-java-8-lambdas-and-streams-can-make-your-code-5-times-slower/

They have the code available, I haven't verified it personally. Also it
is possible the outcome to be different with the newer releases of the
JDK. Please note the difference between the original results and the
updated ones.

The base line is: you have to be extra careful with the streams,
autoboxing and to avoid using lamdas in "hot" places. At least for the
tested use case - "sorting ArrayList populated with 100 000 random
integers".

>> I like the switch to Java 8 to be able to use java build-in code vs.
>> using external dependencies, so my upvote here. But please don’t
>> start changing anything to Java 8 syntactic sugar if it even creates
>> a single object more.
>
> Object creation worries me, for example, when serializing and
> deserializing data. That's what the real returns are in optimization.
> Tiny object creation in non-repeated places is of no importance to me.
>
> Cheers,
>
> Álvaro
>
>> Regards,
>>
>> Daniel Migowski
>>
>> VON: Álvaro Hernández Tortosa [mailto:aht(at)8kdata(dot)com]
>> GESENDET: Montag, 3. April 2017 20:33
>> AN: Daniel Migowski <dmigowski(at)ikoffice(dot)de>; Dave Cramer
>> <pg(at)fastcrypt(dot)com>
>> CC: John R Pierce <pierce(at)hogranch(dot)com>; List
>> <pgsql-jdbc(at)postgresql(dot)org>
>> BETREFF: Re: AW: [JDBC] RFC: Make new versions of pgjdbc Java8+
>>
>> On 03/04/17 20:24, Daniel Migowski wrote:
>>
>>> Hallo,
>>>
>>> in the name of performance, and that should be the main aspect for
>>> a database driver:
>>>
>>> · Don’t use lambdas! They are useful in a GUI where a
>>> few milliseconds are no problem, but shouldn’t IMHO be used on
>>> the server. Inner classes are slower to load but execute faster!
>>>
>>> · Don’t use streams when you can simply iterate over an
>>> array or a list. Unnecessary object creating just for the sake of
>>> readable code? Don’t do this in a database driver either!
>>>
>>> · Optionals: Why create objects for nothing? I’d rather
>>> have an if-check for null instead garbage on the heap.
>>
>> Thank you for your thoughts.
>>
>> I have heard these objections sometimes. I more or less agree
>> with some of them. But don't want to fall into premature
>> optimization: do you have some numbers to back these claims? If
>> there would be performance drawbacks for using these, are they
>> comparable to other performance hits in the driver?
>>
>> Regards,
>>
>> Álvaro
>>
>> Just my thoughts.
>>
>> Regards,
>>
>> Daniel Migowski
>>
>> VON: pgsql-jdbc-owner(at)postgresql(dot)org
>> [mailto:pgsql-jdbc-owner(at)postgresql(dot)org] IM AUFTRAG VON Álvaro
>> Hernández Tortosa
>> GESENDET: Montag, 3. April 2017 13:36
>> AN: Dave Cramer <pg(at)fastcrypt(dot)com>
>> CC: John R Pierce <pierce(at)hogranch(dot)com>; List
>> <pgsql-jdbc(at)postgresql(dot)org>
>> BETREFF: Re: [JDBC] RFC: Make new versions of pgjdbc Java8+
>>
>> On 03/04/17 13:05, Dave Cramer wrote:
>>
>> On 2 April 2017 at 19:03, Álvaro Hernández Tortosa
>> <aht(at)8kdata(dot)com> wrote:
>>
>> On 03/04/17 00:56, John R Pierce wrote:
>>
>> On 4/2/2017 3:40 PM, Álvaro Hernández Tortosa wrote:
>>
>> - Java 6 EOLed 2/2013.
>> - Java 7 EOLed 4/2015.
>> - Java 8 was released 3 years ago, and brought significant
>> improvements.
>> - Java 9 will be (may be) released this year.
>>
>> isn't there a significant lag in version support by things like web
>> services (j2ee, etc, as embedded in things like IBM WebSphere) ?
>> j2ee 8 isn't even out yet. Pretty sure a whole lot of that space
>> is still stuck back in Java 6 land.
>
> Those are not related things. You can perfectly run J2EE 6 servers
> with Java 8 (and indeed, it is beneficial).
>
> Álvaro
>
> --
>
> Álvaro Hernández Tortosa
>
> -----------
> <8K>data
>
> Alvaro,
>
> So why do you want to write in java 8 ?
>
> Not a comprehensive or ordered list, but a few reasons:
>
> - JDK comes with Base64 and cryptographic functions like PBKDF2 that
> are needed for SCRAM. In Java6 you either implement yourself or pull
> external dependencies.
>
> - You can write conciser code (which improves significantly
> readability):
> * Lambas: anonymous classes. Callback-heavy code turns becomes
> readable.
> * Streams: unnecessary for loops and other goodies.
> * Optional: unnecessary ifs.
> * Since Java7: try-with-resources, 10_000 vs 10000 etc.
>
> - Reading Javadoc doesn't hurt my eyes ^_^
>
> - Time API, CompletableFuture.
>
> - Default and static methods in interfaces!
>
> Álvaro
>
> --
>
> Álvaro Hernández Tortosa
>
> -----------
>
> <8K>data
>
> --
>
> Álvaro Hernández Tortosa
>
> -----------
>
> <8K>data
>
> --
>
> Álvaro Hernández Tortosa
>
> -----------
> <8K>data

Cheers,
Radoslav