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]
GenerateTrackingInfo=1
AllowOptimize=0
This allows control of the optimizer outside the build of the assembly, which
is what we want.
(the information is based on
https://blog.matthewskelton.net/2005/04/12/controlling-optimization-and-debug-info-in-release-builds-in-net-applications/,
https://blogs.msdn.microsoft.com/jaredpar/2008/08/29/disabling-jit-optimizations-while-debugging/
and
https://www.hanselman.com/blog/ReleaseISNOTDebug64bitOptimizationsAndCMethodInliningInReleaseBuildCallStacks.aspx.
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.
Vincent
-----Original Message-----
From: Shad Storhaug [mailto:[email protected]]
Sent: Monday, June 12, 2017 11:04 PM
To: [email protected]
Subject: RE: Lucene.net release mode
Vincent,
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:
Lucene.Net.TestFramework.Util.StackTraceHelper
Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyInCommit.Eval()
Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyInSync.Eval()
Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyOnFlush.Eval()
Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyOnTermVectors.Eval()
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...?
Thanks,
Shad Storhaug (NightOwl888)
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Itamar Syn-Hershko
Sent: Monday, June 12, 2017 9:45 PM
To: [email protected]
Subject: Re: Lucene.net 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
http://code972.com | @synhershko <https://twitter.com/synhershko>
http://BigDataBoutique.co.il/
On Mon, Jun 12, 2017 at 4:55 PM, Van Den Berghe, Vincent <
[email protected]> wrote:
> 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
>
