On 07.07.2023 20:09, Herman ten Brugge via Tinycc-devel wrote:
I did a benchmark on linux and it is about 2% slower on my machine.
Well, and how much in comparison is the gain from the ifndef_cache,
in your benchmark? I mean just in case to make sure the cache won't
be slower than no cache after we tried to fix it ;)
I created a new patch where I removed the stat call.
I now calculate the full path name on linux and windows.
This means that soft/hard links do not work any more.
There is still a small slowdown because we create/compare the full path name
now.
But it is about 0.1% on my 64 bits x86_64 machine. Hard to measure correct.
I'd think this would look a lot better if your tiny real/fullpath
replacement were put into its own function.
Plus such thing almost never works right on the first attempt.
(For example tcc might want to try the combination of "-I /include"
with "../../x.h", why not. Rather use the real realpath() then ;)
Anyway, thanks for having showed some options already. What we havn't
seen yet is whether we could maybe handle #pragma once specifically
different as opposed to the #ifndef FOO_H cache. For example there is
no need to check normalized paths at all against files that didn't
have #pragma once (e->once not set).
Obviously similar issues have been seen before elsewhere:
"Bug 58770 - GCC very slow compiling with #pragma once"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770
-- gr
Herman
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
