Marlin does not care about spaces (except on M117), it would be a slight improvement if they would be removed.
Don't know how much of an improvement this could be, but it's an idea.
I know Octoprint still needs to wait for the OK to come back.
This is not really an issue, just a random idea which I'd like to get out of my head.
At high serial speeds, not sure it'll matter much. I looked at a random 2mb file:
So that's about a 10% ratio. Going with 10 bits per byte for serial (start/data/stop bits):
So, what if you could transmit in 480 seconds instead of 530 seconds? Sure, that's a minute of savings, but that's across a couple hours of print time. How much time on an individual command? My longest line is 886 characters, that's under one second even at 9600 baud, it might save 1/10th of a second sending a command.
FWIW, basic gzip compression reduces by 80%, bzip reduces by 86%, zpaq -m5 by 91%, cmix (without preprocessing) by 94%.
cmix was killing my dev machine, so I stuck it on a 16-cpu 64gb ram server. It took 56 minutes.
For fun, acknowledging the Mythbusters "if it's worth doing, it's worth overdoing" rule, I tried on a bare-metal server, 72 cpu/512 gb ram. It still took 50.5 minutes.
For the lulz I should try cmix on a pi3 and a pi zero.
Interesting math exercise though.
You might look into Klipper. It pushes some of the processing from the controller board to the Raspberry Pi 3 in this case. It appears to remove some of the in-print hesitations you might association with surface blobbing, for example.
added cmix results.
Is that what you were doing with the 2nd pi I read on another thread?? Do you have a review of klipper??
No, the Man-in-the-middle is a project which introduces another Pi between the OctoPi instance and the controller. PM me and I'll tell you why one might want to do this. It's a cool project.
The 3D printer manufacturer where I was contracting did a demo of the Klipper replacement for Marlin and it was pretty decent. The surfaces turned out smoother as a result. So you have to imagine that we're accepting poor surface quality because we don't know otherwise.
The basis for the Klipper firmware change is to move the determination of logistics, basically, from the controller board and to push it back to the Raspberry Pi.
10% is way more than what I would define as a slight improvement 
But the improvement here would be on tight turns with a lot of commands, where we could make it more difficult to run into chocking problems.
Keep in mind that the enforced ping pong protocol will reduce these 10%. As will the computational overhead of having to strip spaces from commands (unless you modify them right on upload/in the slicer output).
It should be possible to test though, OctoPrint should not really care on whether you send G1 X0 or G1X0 - the command parsing the comm layer is prepared for that, and as long as the firmware supports this it should work.
That's what the "possible" in the title referred to.
Is the wait for the ok a must if the communication is stable? What would be the consequences of ignoring it?
I'm trying to find some documentation about the protocol, but can't find any (in 5min of googling).
Yes.
Depends on the controller. I've seen controllers that lock up completely when their serial buffer overruns (which would be the consequence of ignoring the ping pong).
Yeah, I'm not surprised. I had to puzzle things together from reading firmware source and observing printers myself.
The basic gist of it is: Host sends line to printer and waits. Printer reads line from serial, processes line, signals that it's ready to receive more by sending back an ok.
The more accurate version (at least for Marlin, other firmware internals can be way different): Host sends line to printer and waits. Printer reads line from serial and puts it into an internal command buffer, unless it's a special command which requires immediate attention, in which case it processes it immediately. Printer then reads next line from command buffer and depending on the command puts it into yet another buffer, or processes it immediately - in any case, it sends back an ok.
Depending on the firmware type and version (= a ton of old vendor forks of Marlin that are still out there and shipped), it will happily acknowledge commands in a different order than they were sent in, so it's impossible to monitor the fill state of any of those three buffers (serial's own RX, command buffer, planner buffer) and bypass the ping pong requirements. Some firmware versions send back info on the last two now, but usually only if it's configured by the user (read: rarely).
Long story short: It's a mess.
A mess it seems to be indeed... Supporting stalled firmwares and quirky forks can be only described as a major headache I assume.
Thanks for the thorough explanation, it gave me a way better insight on the communication "standard".
You stated that we cannot ignore the oks, but what if we have flow control enabled on the firmware (SERIAL_XON_XOFF in Marlin)? That is a feedback that is given on the state of the RX buffer. In that situation maybe we can just open or close the flood gates whenever there is an XON or XOFF respectively?
ADVANCED_OK seems to be exactly what you describe as the buffer state feedback.
EDIT: found if https://github.com/foosel/OctoPrint/issues/2261
See the discussion in
There sadly are some limitations in getting XONXOFF to work since OctoPrint can't react quickly enough (and the serial driver also makes things tricky). I hope to be able to get back to this once I can start experimenting with putting the actual communication into its own sub process.
Bummer 
That was an epic effort.
The reaction time is indeed a tough cookie to chew.
Instead of the XON/XOFF would it be possible to use the response from the ADVANCED_OK to know how many commands could be spam without waiting for an OK?
Yes. The problem here is that with the current implementation that would be tricky to do without losing compatibility to anything that doesn't provide advanced ok. And instead of fiddling around with that, I'm throwing all resources that I can on moving the new comm layer forward (which as of right now can print and all, but still lacks some stuff like temperature offsets, pause triggers, feedback controls, some autodetect things and recovery recording).
I see that everything is planned perfectly.
I still need to get more acquainted with octoprint's internals to start doing useful contributions.
Thank you very much for your time and replies
You're gonna test it, right? It'll be pretty easy to do.
Given @foosel's description of the problem, the real bottleneck seems to be the rtt of the command+ok, so the 10% will not actually be 10% improvement (at all).
I can give it a go nevertheless yes.
I have a Re-Arm I am slowly getting ready to replace my 8 bit AVR for. Now that I see Klipper I dunno that I need it.... My research indicates Klipper uses an entirely different approach to printer kinematics than Marlin. Would I be giving up that approach by using the Re-Arm with Marlin 2.0? I don't see anything that Marlin could be going that direction. What is your take??
Klipper's premise is that the controller board has too much work to do and as a result, it bogs down, resulting in poor quality. It also includes the thought that this work needs to be done sooner versus later.
In a way, it's like compiling a C program so that the runtime code is optimized. The state-of-the-art for 3D printing now is a system of interpreted messages and it makes the controller board have to "think" about things, if you will. Klipper sort of brute-forces the paradigm to make the controller think less.
Would it work on your Re-Arm? In theory, it would.
I'd put it on my own printer but I first need to get the existing (proprietary) Marlin from this in such a way that I can go back if I don't like it.