Reduce binary sizes

[ddkwork]

How to optimize the files built on the Windows platform if they are too large?

[ddkwork]

i was tried use "goki build -v -t windows/amd64" or "go build ."

[kkoreilly]

The binaries are definitely too big, and we will work on reducing binary sizes soon.

[kkoreilly]

In the meantime, simply compressing the binaries (eg: gzip sys.exe) reduces the binary size significantly (about 4x for me on Windows). You can also try more powerful compression tools like brotli.

[kkoreilly]

Though you do have to uncompress them on the target system, it can help when deploying them.

[ddkwork]

Though you do have to uncompress them on the target system, it can help when deploying them.

okay，thx you.

[kkoreilly]

I have cut binary sizes in half in the current version of gi in development by reducing dependencies and cleaning up code. You will not see these changes until I do a release cycle, which will not happen for a few days due to other ongoing changes. I will keep this issue open because there are still many more changes I want to make to further reduce binary sizes.

[ddkwork]

I have cut binary sizes in half in the current version of gi in development by reducing dependencies and cleaning up code. You will not see these changes until I do a release cycle, which will not happen for a few days due to other ongoing changes. I will keep this issue open because there are still many more changes I want to make to further reduce binary sizes.

OKay，but i found the gide's code need update with this change.

[kkoreilly]

I fixed the error in gide.

[ddkwork]

I fixed the error in gide.

After this period of submission, the Android program starts with a black screen or no controls, and the test is files or task manager repository

[kkoreilly]

I am aware of this issue and am working to resolve it as soon as possible.

[kkoreilly]

I fixed the Android app issue in the latest version of gi (go get goki.dev/gi/v2@main).

[kkoreilly]

Also, I figured out a way to get rid of gimain, so you can remove the gimain.Run from all of your code.

[ddkwork]

Also, I figured out a way to get rid of gimain, so you can remove the gimain.Run from all of your code.

cool for you, i will try all.

[ddkwork]

I fixed the Android app issue in the latest version of gi (go get goki.dev/gi/v2@main).

The test found that the two-finger operation DPI scaling did not return to normal

[kkoreilly]

I am aware of that and planning to fix it soon.

[kkoreilly]

I want to keep this open because there are still some binary size issues that I need to resolve.

[ddkwork]

I want to keep this open because there are still some binary size issues that I need to resolve.

okay

[kkoreilly]

The basic Cogent Core hello example is around twice as big, which is because Cogent Core comes with many more features and widgets. As I stated above, we are continuing to work on reducing binary sizes, and we should end up relatively close to gio's size after we make more optimizations soon.

[kkoreilly]

I made further optimizations that reduce the binary size of the basic example by 1.5 MB, and I will continue to work on reducing binary sizes further.

[ddkwork]

I made further optimizations that reduce the binary size of the basic example by 1.5 MB, and I will continue to work on reducing binary sizes further.

I found a detached cgo implementation with a small compilation speed and binary size, and I saw if there was anything to learn,
go mod download github.com/hajimehoshi/ebiten/v2@e8cdf885c05cf2395b1935d7f23c9295dece1f0b

[ddkwork]

[ddkwork]

I have to study this carefully, a long time ago I used fyne packaging font to support Chinese display after the binary volume is very large, wails not to mention, unison is also large, slow compilation, he compiled Chinese display in 1 second and only more than 10MB, this feature must be mined C:\Users\Admin\Desktop\v2.7.0-alpha.9.0.20240225111819-e8cdf885c05c\github.com\hajimehoshi\ebiten\[email protected]\examples\font

[ddkwork]

[kkoreilly]

I don't think the cgo is the main issue, although we may try https://github.com/ebitengine/purego at some point to make cross-compilation easier. The main remaining binary size issues I am aware of and planning to fix are the enumgens, fonts, and icons, which together make up a sizable percentage of the remaining binary size. I will also work on further reducing dependencies if possible.

[ddkwork]

ok

…

---Original--- From: ***@***.***> Date: Mon, Feb 26, 2024 00:40 AM To: ***@***.***>; Cc: ***@***.***>;"State ***@***.***>; Subject: Re: [cogentcore/core] Reduce binary sizes (Issue #733) I don't think the cgo is the main issue, although we may try https://github.com/ebitengine/purego at some point to make cross-compilation easier. The main remaining binary size issues I am aware of and planning to fix are the enumgens, fonts, and icons, which together make up a sizable percentage of the remaining binary size. I will also work on further reducing dependencies if possible. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[MatejMagat305]

sorry for small notice, but with upx (dnf install upx) it is only 4.3 MB that is nice .........

[kkoreilly]

Yep, upx is definitely an effective way to reduce binary sizes, although at some cost. I am considering potential further icon and spelling optimizations to reduce binary sizes more, and I am also planning to work on reducing the size of some of the core code.

[kkoreilly]

Also, if #974 is successful, that should drastically reduce web binary sizes.

[kkoreilly]

I restructured the way instance variables work in typegen such that widgets are now only compiled into the app if they are used, which generally reduces binary sizes by several hundred kilobytes (the demo was reduced by 663.8 kb) (see b1b3f62).

Also, binary sizes are currently temporarily inflated due to large spelling files being embedded into apps, which we are going to fix soon with #711.

[kkoreilly]

We improved the storage of the spelling file in #1001, which reduced binary sizes by 14.0 MB for apps that use text editors! I am also working on icon changes that will reduce binary sizes by 1-2 MB for all apps.

[kkoreilly]

I finished the new icon changes in #1003, which reduce binary sizes by 1.6 MB to 2.1 MB depending on the app.

[kkoreilly]

With those changes complete, binary sizes have been reduced significantly. The main remaining ways to reduce binary sizes are supporting tinygo, removing/optimizing embedded fonts, and cleaning up complex widgets (text fields, text editors, lists, tables, trees, file trees, etc).

[duggavo]

How about moving Yaegi Core to an external repository, outside cogentcore/core? I'm not sure how Go handles dependency, but Yaegi is (relatively) large.

[kkoreilly]

Thank you for the suggestion, but dependencies that you do not import have no effect on binary size. If you do not import yaegicore, it does not impact binary size. If you do not import texteditor, it does not impact binary size, etc. The steps I mentioned in my last comment are still the main options for reducing binary size. We are planning to implement GopherJS support soon.

[AnyCPU]

@kkoreilly is this still relevant issue?

i see that we are already able to exclude "debug" symbols via corresponding build param introduced there 01cce52

or just use explicitly

go build -ldflags="-s -w" ...

also if someone wants to then it is possible to use tools like UPX, but there are more tradeoffs.

it is always possible to open a new issue in case of more specific trouble.

[kkoreilly]

@AnyCPU Thank you for the suggestion, I will close this.

I filed #1473 for the main clear remaining issue. #974 should also help a lot, but that is a separate issue. #1457 may allow us to render text using the HTML canvas API, which would also substantially reduce binary sizes on web, in addition to major performance issues. Given that everything is tracked by separate issues, I will close this.