Originally created by @Omico on GitHub (Feb 4, 2024).
Just play around with pkl. It seems that parsing AST takes a very long time.
TLDR. In my PC, pkl takes 3089 ms, and kotlinx-serialization-properties takes 53 ms.
```
// benchmark.pkl
a {
b {
c {
d = "Hello World!"
}
}
}
// benchmark.properties
a.b.c.d=Hello World!
```
I have created a very simple project for benchmarking. (I didn't use kotlinx benchmark or anything else)
https://github.com/Omico/pkl-benchmark
This example case is somewhat fundamentally going to underperform. kotlinx-serialization-properties just parses this static data. Pkl brings a lot more plumbing out of the box (and will take ~0.5-1s just to load the stdlib). On the tiny static cases like this, Pkl could/should do better, but will never win.
That said, I'd love it if your pkl-benchmark grows out to significantly cover relevant cases!
@holzensp commented on GitHub (Feb 5, 2024):
This example case is somewhat fundamentally going to underperform. `kotlinx-serialization-properties` just parses this static data. Pkl brings a _lot_ more plumbing out of the box (and will take ~0.5-1s just to load the stdlib). On the tiny static cases like this, Pkl could/should do better, but will _never_ win.
That said, I'd _love_ it if your `pkl-benchmark` grows out to significantly cover relevant cases!
Your setup here runs Pkl in the JVM, which means you're also incurring the time it takes for the JVM to bootstrap (e.g. it needs to load classes, fire up our parser, etc)
Performance-wise, Pkl is generally faster if you use the native executables. Here's the same test on my machine using the CLI:
time pkl eval .dan-scripts/test.pkl
a {
b {
c {
d = "Hello World!"
}
}
}
________________________________________________________
Executed in 206.59 millis fish external
usr time 73.38 millis 36.00 micros 73.35 millis
sys time 127.20 millis 907.00 micros 126.29 millis
But, like Phil said, Pkl will never beat a static format, because it is a program that needs to be interpreted, not just parsed.
@bioball commented on GitHub (Feb 5, 2024):
Your setup here runs Pkl in the JVM, which means you're also incurring the time it takes for the JVM to bootstrap (e.g. it needs to load classes, fire up our parser, etc)
Performance-wise, Pkl is *generally* faster if you use the native executables. Here's the same test on my machine using the CLI:
```
time pkl eval .dan-scripts/test.pkl
a {
b {
c {
d = "Hello World!"
}
}
}
________________________________________________________
Executed in 206.59 millis fish external
usr time 73.38 millis 36.00 micros 73.35 millis
sys time 127.20 millis 907.00 micros 126.29 millis
```
But, like Phil said, Pkl will never beat a static format, because it is a program that needs to be interpreted, not just parsed.
Then you can pkl eval benchmark.pkl (or do the equivalent in Java) and get benchmark results!
@bioball commented on GitHub (Feb 6, 2024):
By the way there's also an in-language benchmark suite:
```
// abcd.pkl
a {
b {
c {
d = "Hello World!"
}
}
}
```
```
// benchmark.pkl
amends "pkl:Benchmark"
import "abcd.pkl"
outputBenchmarks {
["abcd"] {
sourceModule = abcd
}
}
```
Then you can `pkl eval benchmark.pkl` (or do the equivalent in Java) and get benchmark results!
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Omico on GitHub (Feb 4, 2024).
Just play around with pkl. It seems that parsing AST takes a very long time.
TLDR. In my PC, pkl takes 3089 ms, and kotlinx-serialization-properties takes 53 ms.
I have created a very simple project for benchmarking. (I didn't use kotlinx benchmark or anything else)
https://github.com/Omico/pkl-benchmark
@holzensp commented on GitHub (Feb 5, 2024):
This example case is somewhat fundamentally going to underperform.
kotlinx-serialization-propertiesjust parses this static data. Pkl brings a lot more plumbing out of the box (and will take ~0.5-1s just to load the stdlib). On the tiny static cases like this, Pkl could/should do better, but will never win.That said, I'd love it if your
pkl-benchmarkgrows out to significantly cover relevant cases!@bioball commented on GitHub (Feb 5, 2024):
Your setup here runs Pkl in the JVM, which means you're also incurring the time it takes for the JVM to bootstrap (e.g. it needs to load classes, fire up our parser, etc)
Performance-wise, Pkl is generally faster if you use the native executables. Here's the same test on my machine using the CLI:
But, like Phil said, Pkl will never beat a static format, because it is a program that needs to be interpreted, not just parsed.
@Omico commented on GitHub (Feb 6, 2024):
Just updated my benchmark, seems not that horrible than before.
@bioball commented on GitHub (Feb 6, 2024):
By the way there's also an in-language benchmark suite:
Then you can
pkl eval benchmark.pkl(or do the equivalent in Java) and get benchmark results!