> 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.
What is the incentive about this ? Feature and usefulness vs speed and benchmark prowess ? Who is going to arbitrate what tcc is supposed to do exactly ? Regards. ----- Mail d'origine ----- De: Herman ten Brugge via Tinycc-devel <tinycc-devel@nongnu.org> À: tinycc-devel@nongnu.org Cc: Herman ten Brugge <hermantenbru...@home.nl> Envoyé: Fri, 07 Jul 2023 20:09:03 +0200 (CEST) Objet: Re: [Tinycc-devel] Relative paths of include files are not normalised, which can break #pragma once On 7/7/23 08:59, grischka wrote: > On 07.07.2023 07:45, draco wrote: >> Hermann, >> >> I tested your patch a bit, seems to work as expected and brings tcc >> win32 back to it's normal speed. > > It might be too slow on linux too ... > > Basically the "#ifndef cache" is meant to make it faster, > while the #pragma once also needs to detect path aliases. > > That is two different goals in the first place. > > Another goal in tinycc is simple code. For example to have > a common solution for platforms. I did a benchmark on linux and it is about 2% slower on my machine. 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. Herman _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel