5 ms·
PartiQL> SELECT * FROM [1,2,3] | ===' << { '_1': 1 }, { '_1': 2 }, { '_1': 3 }
by lwansbrough 7y ago
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!
- dlurton 7y agoThis is on the JVM so the JIT's optimizations probably haven't kicked in yet.
- banachtarski 7y agoWho are we kidding? Even without JIT optimizations that seems absurdly slow.
- dlurton 7y agoAlso, 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.
- pvg 7y agoeach of which becomes a class Wasn't part of the whole thing with lambdas that they don't all become individual classes?
- recursive 7y agoThey're not classes in source code. As an implementation detail, certain compilation strategies do generate them anyway.
- pvg 7y agoWhich ones?
- recursive 7y agoI don't know much about compilers, but basically the ones don't have anywhere else to put the context of a closure.
- pvg 7y agoI don't think that's what happens in the JVM, you can google up the invokevitual + other supporting gunk/mechanism for this.
- recursive 7y agohttps://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.invokevirtual https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.ht... makes plenty of references to dispatching based on class.
- pvg 7y agoD'oh, sorry I sent you on a wild goose chase - you want invokedynamic. Invokedynamic and lambdas.
- jnordwick 7y agothey 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
- paulddraper 7y agoNo, 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.
- pvg 7y agoI 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.
- paulddraper 7y agoYou'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.
- ignoramous 7y agoOther 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 https://partiql.org/tutorial.html
- justicezyx 7y agoYou 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.
- jiggawatts 7y agoYou 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.
- therapon 7y agoIt 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.
- monsieurbanana 7y ago> 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.
- vgt 7y agoWe'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)
- manigandham 7y agoDid 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.