On Mar 5, 11:39 pm, Kenton Varda <ken...@google.com
> As you know if you've read the docs carefully, when using C++ or Java
> protocol buffers, for best performance you need to add a line to your .proto
> option optimize_for = SPEED;
I think there are three issues here:
1) Yes, it's really easy to miss that. Shortly after PBs were released
I saw a blog post showing how "slow" PBs are - and then I pointed out
the optimize_for option...
2) It's a pain to have to use a whole different .proto file just to
specify this option. While I believe many options *should* be in
the .proto file (particularly where they might affect individual
fields etc) I think this would make sense to have as a compiler/
generator flag (it could be in either place, for situations where the
two are split). For instance, you may have a memory-limited client
where speed doesn't matter, and a memory-rich server processing
gazillions of these things - they should be able to use the
same .proto file.
3) Backward compatibility.
I suspect we could really do with the compiler working in four
1) Default to SPEED when otherwise undefined; obey proto file
2) Default to CODE_SIZE when otherwise undefined; obey proto file
otherwise (current mode)
3) Generate code using SPEED regardless of proto file
4) Generate code using CODE_SIZE regardless of proto file
I think it would we should at least be able to specify "I want the old
behaviour" on the command line just because that makes the backward
compatibility story easy: "use this argument and it's all as it was" -
but I'd be happy for the actual default to be changed.
(Evil thought: make the default a build-time setting for the compiler
itself, so if you want to build protoc with the old behaviour you can.
Almost certainly not a good idea, but it's amusing to think of the
number of places this *could* be set...)