starred/pkl
1
0
Fork 0
mirror of https://github.com/apple/pkl.git synced 2026-01-11 22:30:54 +01:00
Code Issues 198 Packages Projects Releases 10 Wiki Activity

UPX the binary so it would save bandwidth #18

New Issue
Open
opened 2025-12-30 01:19:34 +01:00 by adam · 2 comments
adam commented 2025-12-30 01:19:34 +01:00
Owner
Copy Link

Originally created by @kokizzu on GitHub (Feb 4, 2024).

especially for 3rd world countries where internet is slow

upx pkl
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2020
UPX 3.96        Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 23rd 2020

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
  87137256 ->  26604364   30.53%   linux/amd64   pkl

Packed 1 file.
Originally created by @kokizzu on GitHub (Feb 4, 2024). especially for 3rd world countries where internet is slow ``` upx pkl Ultimate Packer for eXecutables Copyright (C) 1996 - 2020 UPX 3.96 Markus Oberhumer, Laszlo Molnar & John Reiser Jan 23rd 2020 File size Ratio Format Name -------------------- ------ ----------- ----------- 87137256 -> 26604364 30.53% linux/amd64 pkl Packed 1 file. ```
adam commented 2025-12-30 01:19:35 +01:00
Author
Owner
Copy Link

@holzensp commented on GitHub (Feb 9, 2024):

I certainly like the idea, but I'm a little hesitant about this (from upx.github.io):

Programs and libraries compressed by UPX are completely self-contained and run exactly as before, with no runtime or memory penalty for most of the supported formats.

I have not had the chance to test, but I think this statement ignores startup time, which we want to be very mindful of. If you know of some benchmarks around this topic, I'm happy to look at it further.

Releasing both the "normal" and the compressed version is also an option, of course, but that makes bug reports (especially around distribution) harder. We are working on getting onto newer versions of GraalVM, which also promises significant reductions in binary size.

@holzensp commented on GitHub (Feb 9, 2024): I certainly like the idea, but I'm a little hesitant about this (from upx.github.io): > Programs and libraries compressed by UPX are completely self-contained and run exactly as before, with no runtime or memory penalty for most of the supported formats. I have not had the chance to test, but I think this statement ignores _startup_ time, which we want to be very mindful of. If you know of some benchmarks around this topic, I'm happy to look at it further. Releasing _both_ the "normal" and the compressed version is also an option, of course, but that makes bug reports (especially around distribution) harder. We are working on getting onto newer versions of GraalVM, which also promises significant reductions in binary size.
adam commented 2025-12-30 01:19:35 +01:00
Author
Owner
Copy Link

@jamesward commented on GitHub (Mar 3, 2024):

Very basic benchmark:

pkl-k8s-examples/pkl/basic $ time pkl eval -f yaml frontend.pkl

...
real	0m0.318s
user	0m0.300s
sys	0m0.016s

With upx -9:

pkl-k8s-examples/pkl/basic $ time pkl-upx eval -f yaml frontend.pkl

...

real	0m0.580s
user	0m0.531s
sys	0m0.045s

So definitely some overhead but not sure if it is acceptable amount.

Another option since some of Pkl is written in Kotlin is Kotlin/Native which produces much smaller binaries. But that'd be a much larger re-write since all of the JVM dependencies would have to be replaced and there may not be existing alternatives yet. Just for reference, a very basic "hello, world" with Kotlin/Native (source):

hello-kotlin-native $ ls -al build/bin/linuxX64/releaseExecutable/hello-kotlin-native.kexe
-rwxrwxr-x 1 jw jw 468376 Mar  3 09:18 build/bin/linuxX64/releaseExecutable/hello-kotlin-native.kexe

hello-kotlin-native $ time build/bin/linuxX64/releaseExecutable/hello-kotlin-native.kexe
hello, world

real	0m0.005s
user	0m0.001s
sys	0m0.005s

hello-kotlin-native $ upx -9 build/bin/linuxX64/releaseExecutable/hello-kotlin-native.kexe
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2024
UPX 4.2.2       Markus Oberhumer, Laszlo Molnar & John Reiser    Jan 3rd 2024

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
    468376 ->    142188   30.36%   linux/amd64   hello-kotlin-native.kexe  

hello-kotlin-native $ time build/bin/linuxX64/releaseExecutable/hello-kotlin-native.kexe
hello, world

real	0m0.009s
user	0m0.009s
sys	0m0.000s

Side note, that with Kotlin Multiplatform, you could have both the native and the JVM library outputs so Pkl wouldn't lose the JVM library like they would if they went Rust, Go, etc.

@jamesward commented on GitHub (Mar 3, 2024): Very basic benchmark: ``` pkl-k8s-examples/pkl/basic $ time pkl eval -f yaml frontend.pkl ... real 0m0.318s user 0m0.300s sys 0m0.016s ``` With `upx -9`: ``` pkl-k8s-examples/pkl/basic $ time pkl-upx eval -f yaml frontend.pkl ... real 0m0.580s user 0m0.531s sys 0m0.045s ``` So definitely some overhead but not sure if it is acceptable amount. Another option since some of Pkl is written in Kotlin is Kotlin/Native which produces much smaller binaries. But that'd be a much larger re-write since all of the JVM dependencies would have to be replaced and there may not be existing alternatives yet. Just for reference, a very basic "hello, world" with Kotlin/Native ([source](https://github.com/jamesward/hello-kotlin-native)): ``` hello-kotlin-native $ ls -al build/bin/linuxX64/releaseExecutable/hello-kotlin-native.kexe -rwxrwxr-x 1 jw jw 468376 Mar 3 09:18 build/bin/linuxX64/releaseExecutable/hello-kotlin-native.kexe hello-kotlin-native $ time build/bin/linuxX64/releaseExecutable/hello-kotlin-native.kexe hello, world real 0m0.005s user 0m0.001s sys 0m0.005s hello-kotlin-native $ upx -9 build/bin/linuxX64/releaseExecutable/hello-kotlin-native.kexe Ultimate Packer for eXecutables Copyright (C) 1996 - 2024 UPX 4.2.2 Markus Oberhumer, Laszlo Molnar & John Reiser Jan 3rd 2024 File size Ratio Format Name -------------------- ------ ----------- ----------- 468376 -> 142188 30.36% linux/amd64 hello-kotlin-native.kexe hello-kotlin-native $ time build/bin/linuxX64/releaseExecutable/hello-kotlin-native.kexe hello, world real 0m0.009s user 0m0.009s sys 0m0.000s ``` Side note, that with Kotlin Multiplatform, you could have both the native and the JVM library outputs so Pkl wouldn't lose the JVM library like they would if they went Rust, Go, etc.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
good first issue
help wanted
pull-request
Mirrored from GitHub Pull Request
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pkl#18
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?