To the compiler there is no difference between input that come from a .cxx file or a .h file, this text gets compiled into the same unit of translation.
The main reason why we typically do not put code inside header files, is to avoid duplicate objects, which then conflict at the level of the linker, when a given header is be used by multiple .cxx files.
Maybe you are confusing inline functions with macros, for in the case of macros, which are essentially a pre-processing directive, there is no risk of linker-time conflicts, even when/if the same headers where included multiple times for different units of translation.
It is of course possible to define functions in the headers (or elsewhere), in a way which instructs the compiler to systematically inline the calls to the function, and in such cases there is also no conflict at link time. However this require special syntax, and is merely implied by the fact that code comes from an include file or a cpp file (as the question suggests).
Now, to answer the question, per se, moving all this code out of header files and into cpp files, should not have much of an impact on either the binary size nor on performance.
Apparently, if the function definitions in the header files were not inlined explicitly, there must have only one user of the header file per different exe/dll produced (otherwise there'd be duplicates at link time), and therefore the file would not change in either direction.
With regards to performance, with the general performance gains in the hardware, even if functions formerly inlined were to be now called normally, this should go generally unnoticed, performance-wise, with possible exception of particular tight loops, where the logic iterates very many times.