Hacker News Reader

Comment by lwansbrough | Hacker News Reader

    PartiQL> SELECT * FROM [1,2,3]
       | 
    ===' 
    <<
      {
        '_1': 1
      },
      {
        '_1': 2
      },
      {
        '_1': 3
      }
    >>
    --- 
    OK! (86 ms)

Jeez. 86ms for this query on this data set? Hope that's not representative of the general performance!

View on HN

Other queries involving joins, aggregates, unrolls, and pivots on schemaless, nested, multi-path documents performed way better than the example cherry-picked from the main blog post-- Queries completing between 5ms to 25ms, albeit on toy dataset.

https://partiql.org/tutorial.html

You missed the point. The modern infrastructure's primary value is scalability. This number is of course bad, for the data. But this number will be more impressive when the data is million time bigger.

You missed the point. Modern infrastructure's scalability is irrelevant if even one user's experience is poor.

In the era of 64-core processors, scaling horizontally is meaningless for 99.9% of architecture designs. Latency matters to everyone, always.

Trivial queries taking nearly 1/10th of a second on modern kit is absolutely atrocious, and shows a total lack of awareness of performance as a feature.

It looks like the first query run in the REPL takes more time (startup cost). Subsequent runs of that query return around 5ms. Even a query like `SELECT * FROM 1` when executed immediately after starting the REPL will take longer than usual. Even running non-query expression, e.g., `1 + 1` immediately after starting the REPL will take more time to complete than usual.

The time reported by the REPL can be misleading.

There is work that we definitely need to do on performance as we develop PartiQL. Performance is something we have been considering since inception and we will keep considering as we go forward.

> Latency matters to everyone, always.

I used to do a lot of BigQuery for analytics. Latency in BigQuery is crap and clearly not it's selling point, we're not talking ms here, we're talking seconds at a minimum. Yet it's a really nice database for it's use cases.

We've improved our floor latency by a factor of 5 since two years ago, we've introduced clustering, and newly introduced BI engine gets you into dozen digit millisecond range, so give it a try again :)

(Product manager on BigQuery)

I mean modern infrastructure's user experience is very poor compared to decades ago's PC based software...

This is on the JVM so the JIT's optimizations probably haven't kicked in yet.

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

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.

each of which becomes a class

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

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

Which ones?

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

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

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

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

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

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.

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.

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.

Did you just copy/paste from the tutorial?

It's an early reference implementation and demo program to show off the language syntax, it doesn't have much to do with whatever engine actually executes the query and that will be the majority of any real query's timing.

Regardless, even the query parsing and compilation should be much faster if it moves into lower-level language like C++ or Rust.

Reply on news.ycombinator.com