Getting Environment Variables is few times slower on Linux

[adamsitnik]

Slower	Lin/Win	Win Median (ns)	Lin Median (ns)	Modality
System.Tests.Perf_Environment.ExpandEnvironmentVariables	4.06	155.25	630.15
System.Tests.Perf_Environment.GetEnvironmentVariable	3.94	139.77	550.89
System.Tests.Perf_Environment.GetEnvironmentVariables	1.56	15955.73	24816.14	several?

How to run the benchmarks:

git clone https://github.com/dotnet/performance.git
python3 ./performance/scripts/benchmarks_ci.py -f netcoreapp5.0 --filter 'Perf_Environment'

Recommended profilers are PerfCollect and VTune.

[adamsitnik]

I've taken a brief look at Environment.GetEnvironmentVariable and it looks like most of the time is spent for doing text operations: getting length of the key (which is known up-front), converting Unicode to Utf8 and then searching for the key in the array:

[Ulisse67]

I think, as a quick fix, that the check by length could be scrapped and just strcmp() could be used, if it doesn't use strlen() internally :-)

Oh oh, I got now to profile the code and I see why strncmp is needed (because of = in env entries).

[adamsitnik]

dotnet/corefx#27632 did not solve the problem

[Ulisse67]

I've tried to implement strncmp as an explicit loop:

int search_pointers(const char* name, const char** palEnvironment)
{
	if (name[0] == '\0')
		return -1;

	for (int i = 0; palEnvironment[i] != nullptr; ++i) {
		char ch;
		const char* pch = name;
		const char* p = palEnvironment[i];

		while ((ch = *pch++) && ch == *p++)
			;

		if (ch == '\0') return i;
	}

	return -1;
}

and the profiler shows a good improvement (based on 1E8 iterations over a list of 6 entries looking for the last entry):

[Ulisse67]

I've been able to shave off some percent:

by rewriting the inner tests of the compare loop:

int search_pointers3(const char* name, const char** palEnvironment)
{
	if (name[0] == '\0')
		return -1;

	for (int i = 0; palEnvironment[i] != nullptr; ++i) {
		const char* pch = name;
		const char* p = palEnvironment[i];

		for (;;) {
			if (*pch == '\0') return i;

			if (*pch++ != *p++) break;
		}
	}

	return -1;
}

[adamsitnik]

@Ulisse67 it would be great if you could run our benchmarks and confirm the improvements

How to build CoreCLR in Release:

./build.sh -release
./build-test.sh release generatelayoutonly

Once you run those two commands you should get an executable called corerun which is a simplified .NET Core exe runner. You need to use it to run the benchmarks.

Example:

git clone https://github.com/dotnet/performance.git
python3 ./performance/scripts/benchmarks_ci.py -f netcoreapp5.0 --filter 'Perf_Environment' --corerun /home/adam/projects/coreclr/bin/tests/Linux.x64.Release/Tests/Core_Root/corerun

[jkotas]

It may be also worth looking at inlining check for the first character only that filters most of the negatives, and still call strncmp for the rest.

[Ulisse67]

It may be also worth looking at inlining check for the first character only that filters most of the negatives, and still call strncmp for the rest.

It makes a difference, indeed:

I'm going to build and run the official benchmarks.

[Ulisse67]

I had finally the time to build CoreCLR on my machine (WSL1 within Win10) and have run the performance tests for a version with strncmp + lookahead(1):

And then for a version using pointers:

static char* match_prefix(const char* name, char** list)
{
	if(*name == '\0')
		return nullptr;
	
	for (int i = 0; list[i] != nullptr; ++i)
	{
		const char* pch = name;
		char* p = list[i];

		for (;;) {
			if (*pch == '\0') {
				if(*p == '=')
					return p+1;
					
				if(*p == '\0') // no = sign -> empty value
					return p;
				
				break;
			}
			
			if (*pch++ != *p++) break;
		}
	}
	
	return nullptr;
}
	
char* EnvironGetenv(const char* name, BOOL copyValue)
{
	CPalThread * pthrCurrent = InternalGetCurrentThread();
	InternalEnterCriticalSection(pthrCurrent, &gcsEnvironment);
	
	char* retValue = match_prefix(name, palEnvironment);
	
	if ((retValue != nullptr) && copyValue)
	{
		retValue = strdup(retValue);
	}

	InternalLeaveCriticalSection(pthrCurrent, &gcsEnvironment);
	return retValue;
}

[adamsitnik]

It looks like you got 10% improvement, nice!

[Ulisse67]

Do I have to make a PR?

[adamsitnik]

Do I have to make a PR?

Yes, please!

We have merged CoreFX and CoreCLR repositories into https://github.com/dotnet/runtime, so please send your PR to the new repo

[danmoseley]

Can environment variable names or values in Linux ever be non ASCII (ie., UTF-8)? If so will this "raw pointer" approach still be OK? (eg., will it see = that is somehow a second or subsequent byte of a codepoint)

[Ulisse67]

I believe the equal sign has one 8-bit code even in UTF-8; there are two other equal signs (above= and under=) which use 2 bytes each, but I don't think is legal for specifyfing an environment variable.

Even using UTF-8 for keys would not invalidate the pointer (or strncmp()) approach, because UTF-8 is defined to be backwards compatible with zero-terminated strings, and thus all related idioms keep working.