cogentcore / core

A free and open source framework for building powerful, fast, elegant 2D and 3D apps that run on macOS, Windows, Linux, iOS, Android, and the web with a single Go codebase, allowing you to Code Once, Run Everywhere.
http://cogentcore.org/core
BSD 3-Clause "New" or "Revised" License
1.68k stars 79 forks source link

Reduce binary sizes #733

Open ddkwork opened 8 months ago

ddkwork commented 8 months ago

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

ddkwork commented 8 months ago

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

kkoreilly commented 8 months ago

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

kkoreilly commented 8 months ago

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 commented 8 months ago

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

ddkwork commented 8 months ago

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

okay,thx you.

kkoreilly commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

I fixed the error in gide.

ddkwork commented 8 months ago

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 commented 8 months ago

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

kkoreilly commented 8 months ago

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

kkoreilly commented 8 months ago

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

ddkwork commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

kkoreilly commented 7 months ago

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

ddkwork commented 7 months ago

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

okay

kkoreilly commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago
{317207F5-A9AE-4276-810E-CA5F6177E3C4}
ddkwork commented 6 months ago
{1F93CFA0-FECE-41e4-ABCE-487387C28D68}

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\v2@v2.7.0-alpha.9.0.20240225111819-e8cdf885c05c\examples\font

ddkwork commented 6 months ago

screenshots

kkoreilly commented 6 months ago

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 commented 6 months ago

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 commented 2 months ago

sorry for small notice, but with upx (dnf install upx) it is only 4.3 MB that is nice ......... Screenshot from 2024-06-17 20-14-00

kkoreilly commented 2 months ago

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 commented 2 months ago

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

kkoreilly commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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.