proc_macro: stop using LEB128 for RPC.

[eddyb]

I'm not sure how much of an improvement this creates, it's pretty tricky to measure.

[eddyb]

@bors try

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[bors]

⌛ Trying commit 6688b03 with merge 20daaaa5587a335a502951a2e9cd465973bed0a9...

[bors]

☀️ Try build successful - checks-travis
Build commit: 20daaaa5587a335a502951a2e9cd465973bed0a9

[nnethercote]

@rust-timer build 20daaaa5587a335a502951a2e9cd465973bed0a9

[rust-timer]

Success: Queued 20daaaa5587a335a502951a2e9cd465973bed0a9 with parent 3750348, comparison URL.

[rust-timer]

Finished benchmarking try commit 20daaaa5587a335a502951a2e9cd465973bed0a9

[nnethercote]

The comparison URL suggests it's a very slight win. But Cachegrind says it's a big win for webrender_api (in #59650):

• Before: 22,506,640,384 instructions
• After: 20,777,560,703 instructions

That's an almost 8% reduction.

I admit I don't understand why this change causes an improvement...

[nnethercote]

Local profiling results:

webrender_api-check
avg: -4.6% min: -7.7% max: -3.2%
webrender_api-opt
avg: -3.1% min: -7.3% max: -0.9%
webrender_api-debug
avg: -4.0% min: -6.7% max: -2.5%

[eddyb]

This is a classical "time vs memory" tradeoff: by encoding the original integer's bytes, with no "compression", the CPU has to spend roughly one instruction instead of a loop with several instructions per each 7-bit chunk of the integer, not to mention the branching itself.

Because we're only serializing a fixed number of integers per request/response, the memory overhead is tiny and constant, so LEB128 was never really called for.

Feel free to approve this PR if you think it helps, or get @alexcrichton to review it, I guess.

[alexcrichton]

I don't mind going either way on this, but I'd be fine waiting for a compelling use case to switch

[nnethercote]

The profiling results above are compelling enough for me.

@bors r+

[bors]

📌 Commit 6688b03 has been approved by nnethercote

[fedochet]

@eddyb sorry to bother you so long after this PR is closed, but still: does this change breaks ABI for the procedural macros compiled before this change?
More concretely: is calling procedural macros, compiled with compiler before this update, from code, compiled with compiler after this update (using proc_macro::bridge::client API), will lead to errors and panics?
I am currently experiencing errors during macro expansions, and they are quite hard to debug. The errors I got are something like thread 'main' panicked at 'index 4 out of range for slice of length 1', and I believe they are coming from this changed code

[eddyb]

@fedochet There is no such thing as ABI stability here, Cargo should be recompiling your proc macros for you.

[fedochet]

@eddyb but if I am using precompiled procedural macros and their exported functions outside of compiler and load them by hand (basically to emulate procedural macro expansion)?

[eddyb]

Then you have to emulate what Cargo does and rebuild everything every time the output of rustc -vV changes in any way.

[fedochet]

Is there any chance that proc_macro ABI/API will be stabilized? I've seen a note in the rustc sources that in future procedural macros may be implemented as executables of some sort. They are now in fact, but without reliable ABI it's not safe to use them in external tools (my use case, for example, is providing autocompletion in IDE based on procedural macros expansion)

[eddyb]

@fedochet There are no plans for a stable ABI in Rust. In general, you must recompile everything built by rustc when you change its version (with the sole exception of a staticlib / cdylib with a C API of your choosing).
It's all quite safe as long as you validate rustc -vV the same way Cargo does on every build.

[fedochet]

@eddyb please take a look at #60593 - if this problem is real (i hope it's not just on my machine), it is very strange, because you've suggested that I should use the same compiler to compile everything, and from what I'm experiencing it is the only setup that doesn't work (which is, again, very strange)