PartiQL: One query language for all your data

Re:PartiQL: One query language for all your data by banachtarski on Thursday August 01, 2019 @05:25PM (#20588523)

Who are we kidding? Even without JIT optimizations that seems absurdly slow.

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by dlurton on Thursday August 01, 2019 @05:32PM (#20588564)

Also, the PartiQL compiler makes heavy use of closures, each of which becomes a class, so the first time a query executes the JVM has to load a few dozen classes--this probably explains the 86ms more than a lack of JIT optimizations alone.

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by pvg on Thursday August 01, 2019 @05:44PM (#20588672)

each of which becomes a class

Wasn't part of the whole thing with lambdas that they don't all become individual classes?

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by paulddraper on Thursday August 01, 2019 @08:39PM (#20589772)

No, the point of lambdas is you didn't have to write the full class syntax.

Like in other OO languages, every value in Java is an object [1], and every object has a class.

[1] Except for the 8 primitive types.

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by pvg on Thursday August 01, 2019 @08:50PM (#20589820)

I didn't say that was 'the point of lambdas'. But the lambdas implementation, as far as I know, doesn't make new classes. It's not syntactic sugar around anon/inner classes.

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by paulddraper on Thursday August 01, 2019 @09:33PM (#20590035)

You're right that it's not represented as a class in byte code.

At runtime, LambdaMetafactory creates function objects that implement the require interfaces.

The objects are instances of java.lang.Object, including returning a value for getClass() that is the same as for any other other lambda objects created from same expression.

Not compile time classes, but runtime instances of classes.

Uses different machinery with keeping compatibility.

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by recursive on Thursday August 01, 2019 @07:12PM (#20589240)

They're not classes in source code. As an implementation detail, certain compilation strategies do generate them anyway.

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by pvg on Thursday August 01, 2019 @07:40PM (#20589409)

Which ones?

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by recursive on Friday August 02, 2019 @03:02PM (#20595643)

I don't know much about compilers, but basically the ones don't have anywhere else to put the context of a closure.

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by pvg on Friday August 02, 2019 @03:35PM (#20595910)

I don't think that's what happens in the JVM, you can google up the invokevitual + other supporting gunk/mechanism for this.

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by recursive on Friday August 02, 2019 @11:00PM (#20598372)

https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.ht... makes plenty of references to dispatching based on class.

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by pvg on Friday August 02, 2019 @11:11PM (#20598407)

D'oh, sorry I sent you on a wild goose chase - you want invokedynamic. Invokedynamic and lambdas.

[ Parent | on HN ]

Re:PartiQL: One query language for all your data by jnordwick on Thursday August 01, 2019 @07:12PM (#20589241)

they use invokedynamic instruction so a little more efficient than a class once jit'ed (for hotspot, not sure about the other jvms). there might be some cases where class generation is needed, but i don't think so

[ Parent | on HN ]