lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Van Den Berghe, Vincent" <>
Subject RE: release mode
Date Tue, 13 Jun 2017 08:40:24 GMT
Understood. And I know that the speed of a nonworking program is irrelevant, so these tests
should be done one way or another.

What surprised me, however, is the huge price to pay in terms of performance, even with small
document collections.
Just removing the attribute and compiling in release mode increases indexing speed by 40%
for 64-bit builds (i.o.w. running time with this release build was 60% less than the build
with the attribute). In my case, allowing JIT optimizations is very significant, and I assume
it will be for others as well. It's like driving a car with the handbrake on.

One possible way of having your cake and eat it too is to remove the attribute, compile in
release mode (possibly with the /debug:pdbonly which has zero effect on the quality of the
generated code, but this is optional), and launch the tests using a wrapper executable (TestWrapper.exe)
with a TestWrapper.ini  containing this:

	[.NET Framework Debugging Control] 

This allows control of the optimizer outside the build of the assembly, which is what we want.
(the information is based on,

I know the trick works in regular .NET, but I have insufficient knowledge of .NET Core or
the test framework to know if this is applicable in these cases as well. This is left for
you experts.


-----Original Message-----
From: Shad Storhaug [] 
Sent: Monday, June 12, 2017 11:04 PM
Subject: RE: release mode


Running the tests in Release mode must be done to ferret out the issues that occur when the
compiler removes Debug.Assert statements that change state. Apparently, these statements are
not removed in Java, so we have to be vigilant about testing this condition in .NET to ensure
it will work right without them.

I think it is a good idea to find a better way to do this than the Debuggable attribute -
at the time I was just trying to get over all of the hurdles to make the tests run successfully
so we could release, and this was the first solution I could find that worked. The tests rely
on specific information to be in the stack trace in order to succeed, and the way it is determined
is different between .NET Framework and .NET Core. See:


As long as we can find a way to make these tests work, I have no issue with changing it. IMO,
using stack trace information is a horrible thing to test for, anyway - it would be better
to inject some kind of test helper that tracks what phase the index writer is in and read
its state directly from the test, but I am not sure how difficult that would be. Perhaps there
is a way to use a decorator pattern around the components in question to track whether a specific
method is currently being executed...?

Shad Storhaug (NightOwl888)

-----Original Message-----
From: [] On Behalf Of Itamar
Sent: Monday, June 12, 2017 9:45 PM
Subject: Re: release mode

Sounds legit to me. Generating and distributing pdb's is the way to go, unless there is something
preventing us from doing this. Shad? Connie?


Itamar Syn-Hershko
Freelance Developer & Consultant
Elasticsearch Partner
Microsoft MVP | Lucene.NET PMC | @synhershko <>

On Mon, Jun 12, 2017 at 4:55 PM, Van Den Berghe, Vincent <>

> Hello everyone,
> I'm seeing the following in AssemblyInfo.cs:
> // LUCENENET NOTE: This attribute is required to disable optimizations 
> so the // 
> Lucene.Net.Tests.Index.TestIndexWriterExceptions.TestExceptionsDuringC
> ommit()
> test
> // can read the stack trace information, otherwise the test fails.
> [assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | 
> DebuggableAttribute.DebuggingModes.DisableOptimizations)]
> This effectively disables optimizations in release mode.
> However, removing this attribute is removed doesn't seem to affect the 
> "TestExceptionsDuringCommit" test. Moreover, this test doesn't seem to 
> read stack trace information, unless there is something that I'm missing.
> If stack trace information is needed in release mode, one could 
> consider generating PDB information. Yes, optimization will sometimes 
> cause the information to be incorrect, but the probability of having 
> bugs in release mode that can't be reproduced in debug mode is relatively small, IMHO.
> What say the esteemed colleages?
> Vincent
View raw message