On 24.03.2025 16:49, Charles Blake wrote:
On Linux if you just
echo 'int main(int ac,char**av){return 0;}' >/dev/shm/true.c
And then time (with high resolution) `tcc -run /dev/shm/true.c`,
you get execution time about 2X longer than the same with `tcc -c`.
tcc -c doesn't load libraries ...
Running strace on the linking revealed hundreds of read(,,1)'s.
Looking into it further, these are all from tccelf.c:ld_inp()
which it seems was added by grischka in 2019 for multi-threading.
I might even guess the unbuffered reads were a "placeholder" that
never got replaced.
If you first apply the attached patch and do the same thing, most
unneeded system call overhead vanishes and the end-to-end time (of,
yes, that trivial program) gets 1.35X better (on an i7-6700k it goes
down to 750 microsec from 1000 microsec with statistical errors
around +-10 microsec).
Everything very good, except what is the scenario where the
difference of 0.00025 seconds would matter?
The size expansion of TCCState is not so
bad -- 272 bytes added to the 1808 byte struct or +15%.
By any means, you could allocate the buffer & variables on the
stack and just have a pointer in the state, like
ST_FUNC int tcc_load_ldscript(TCCState *s1, int fd)
{
...
struct ld_io io = { fd, 0, 0, {0} };
s1->ld_io = &io;
-- gr
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
