Reduce the binary size

[DOsinga]

Haven't looked closely into this, but our release binary is huge. We should look into how come and what we can do about it

[shawn111]

There's a short discuss about reduce size of goose.

@cgwalters "A quick git annotate shows this came in with #2654 which may be a good place to ping..."

https://discord.com/channels/1287729918100246654/1344318255266795641/1402457766244778075

[shawn111]

• webbrowser: Versions 0.8 and 1.0.
• anyhow: Versions 1.0 and 1.0.94.
• tokio: Versions 1 and 1.43.
• serde: Versions 1.0 and 1.0.216.
• serde_json: Versions 1.0 and 1.0.133.
• once_cell: Versions 1.19 and 1.20.2.
• async-trait: Versions 0.1.86, 0.1, and 0.1.83.
• base64: Versions 0.22.1, 0.21, and 0.22.
• chrono: Versions 0.4 and 0.4.38.
• reqwest: Versions 0.11 and 0.12.9.

These duplications likely stem from the project's use of a workspace where individual crates can
still specify their own dependency versions, a lack of strict versioning, or independent
development efforts. While some minor version differences might be compatible, they can lead to
increased binary size, slower compilation times, and potential for subtle bugs.

[shawn111]

If we let goosed handle the core / heavy parts like vector_db

Then goose-cli-lite will be super lite.

goose-cli (lite)
                             >>>>>>          goosed 
goose-ui
 ----------------------------------------------------------
 agent (built-in mcp)
                             <<<<<<          
  (dev-env, computer control)

[DOsinga]

Thanks, this is good research. We're going to remove lancedb, so that should help a bunch. also good points on the different crates. one thing I had been thinking about is, what if goosed and goose-cli would be the same binary?

I think also optimizing the build settings could help:

bloaty target/release/goose                          
    FILE SIZE        VM SIZE    
 --------------  -------------- 
  66.8%  85.9Mi  66.8%  85.9Mi    __TEXT,__text
  11.1%  14.3Mi  11.1%  14.3Mi    __TEXT,__const
   9.2%  11.9Mi   9.2%  11.9Mi    __TEXT,__eh_frame
   4.7%  6.07Mi   4.7%  6.07Mi    __TEXT,__gcc_except_tab
   4.3%  5.54Mi   4.3%  5.54Mi    __DATA_CONST,__const
   1.6%  2.09Mi   1.6%  2.09Mi    __TEXT,__unwind_info
   1.0%  1.29Mi   1.0%  1.29Mi    Export Info
   0.8%  1021Ki   0.8%  1021Ki    Code Signature
   0.2%   321Ki   0.2%   321Ki    Function Start Addresses
   0.1%   147Ki   0.1%   147Ki    Rebase Info
   0.1%  83.4Ki   0.1%  83.4Ki    __DATA,__data
   0.0%  36.3Ki   0.0%  36.3Ki    __TEXT,__cstring
   0.0%  18.3Ki   0.0%  19.9Ki    [13 Others]
   0.0%       0   0.0%  13.4Ki    __DATA,__common
   0.0%  12.7Ki   0.0%  12.8Ki    [__TEXT]
   0.0%  8.47Ki   0.0%  3.61Ki    [__DATA]
   0.0%  6.97Ki   0.0%  6.97Ki    Lazy Binding Info
   0.0%       0   0.0%  6.07Ki    __DATA,__bss
   0.0%  5.53Ki   0.0%  5.53Ki    Symbol Table
   0.0%  5.09Ki   0.0%  5.09Ki    String Table
   0.0%  3.95Ki   0.0%  3.95Ki    __TEXT,__stub_helper
 100.0%   128Mi 100.0%   128Mi    TOTAL

[shawn111]

How about let vetordb as a cargo feature, first?

BTW, when I tried build goose on termux, Cross.rs still use ubuntu 20.04.
It will not support the latest xcap and lancedb.

[DOsinga]

we've removed the vector db stuff