Comments (7)
0.0196?
There are a few options already to reduce the size of the generated code:
This would leave only functions needed for encode and decode. Is this what you are looking for?
from gpb.
0.0196?
There are a few options already to reduce the size of the generated code:
This would leave only functions needed for encode and decode. Is this what you are looking for?
{gpb_opts, [
{i, "priv/protobuf/"},
{module_name_suffix, "_p"},
% {o, "path/to/out_dir"}, %% both .erl and .hrl are generated here
{o_erl, "src/game_protobuf"},
{o_hrl, "include/"},
{strings_as_binaries, false},
{packed, true},
{gen_introspect,false},
{gen_verifiers,false}
]}.
Is this the configuration? In rebar3 config
But it doesn't seem to have taken effect, and the generated file hasn't changed
from gpb.
For me, your configuration works, and the options do make a difference. Did you clean first? Maybe it will not rebuild if only the options have changed.
from gpb.
For me, your configuration works, and the options do make a difference. Did you clean first? Maybe it will not rebuild if only the options have changed.
I confirm that the configuration has taken effect, and I have changed the file suffix to generate a different file.
Only one protocol generated over a thousand lines of code
from gpb.
In general, the layout of the generated code is the way it is in order to exploit as much as possible of the optimizations that the Erlang compiler and beam vm can do. It would likely be quite a bit of work to add an option to make the generated code smaller, plus there will be more maintenance. What is the reason why you want the code to be smaller? It is unlikely that I will spend an effort just based on opinions.
from gpb.
In general, the layout of the generated code is the way it is in order to exploit as much as possible of the optimizations that the Erlang compiler and beam vm can do. It would likely be quite a bit of work to add an option to make the generated code smaller, plus there will be more maintenance. What is the reason why you want the code to be smaller? It is unlikely that I will spend an effort just based on opinions.
Because the protocol files I generate when using other protocols are relatively small, I am not used to using GPB because my project generates a large number of protocol files. If the protocol files can be smaller, it can reduce the project's compilation time.
Thank you very much for your answer. :)
from gpb.
Thanks for the explanation. If the are many imported .proto files, then you can reduce the number of compiled files, and thus the compilation time. It is sufficient to generate code only the top-level .proto files, ie only for those that are not imported by some other. For example if a.proto imports b.proto and c.proto, then generate for only the a.proto. You can do this with the f
option in rebar3_gpb_plugin: {f, ["file1.proto", "file2.proto"]}
- allows you to specify a subset of all proto files found. But it will unfortunately be a bit large.
from gpb.
Related Issues (20)
- There are many deficiencies HOT 6
- Hitting `no case clause matching: :group_end` in Elixir app using Exprotobuf/gpb HOT 8
- Add preprocessor check around no_underspec? HOT 3
- Optional added back to proto3 HOT 3
- Outdated example HOT 3
- Unset `google.protobuf.StringValue` map values are decoded as empty strings instead of empty values HOT 3
- proposal for performance improvements HOT 9
- Performance improvement for encoding protos with unchanged data HOT 7
- -spec for enum generated code is incorrect HOT 3
- For gpb 5: Drop support for Erlang versions before 19
- How can i call gpb from my rebar.config? HOT 2
- [enhancement] support for gpb text format HOT 1
- -mapfields-as-maps and -json possible incompability HOT 2
- Trying to ecode a float into a uint64 field results in a badarith exception instead of gpb_type_error HOT 2
- Enums are not defined as macros HOT 7
- Fix for warning on float 0.0 HOT 5
- to_json encodes `uint64` as an integer instead of a string HOT 1
- Add a @generated tag HOT 1
- Excessive File Size in Generated Protobuf Files HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gpb.