You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by "Van Den Berghe, Vincent" <Vi...@bvdinfo.com> on 2017/06/12 13:55:00 UTC
Lucene.net release mode
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.TestExceptionsDuringCommit() 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
RE: Lucene.net release mode
Posted by "Van Den Berghe, Vincent" <Vi...@bvdinfo.com>.
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:shad@shadstorhaug.com]
Sent: Monday, June 12, 2017 11:04 PM
To: dev@lucenenet.apache.org
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: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On Behalf Of Itamar Syn-Hershko
Sent: Monday, June 12, 2017 9:45 PM
To: dev@lucenenet.apache.org
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 < Vincent.VanDenBerghe@bvdinfo.com> 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
>
RE: Lucene.net release mode
Posted by Shad Storhaug <sh...@shadstorhaug.com>.
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: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On Behalf Of Itamar Syn-Hershko
Sent: Monday, June 12, 2017 9:45 PM
To: dev@lucenenet.apache.org
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 < Vincent.VanDenBerghe@bvdinfo.com> 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
>
Re: Lucene.net release mode
Posted by Itamar Syn-Hershko <it...@code972.com>.
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 <
Vincent.VanDenBerghe@bvdinfo.com> 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.TestExceptionsDuringCommit()
> 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
>