schemeshard: make reboot tests run faster

Speedup schemeshard tests with reboots (by 2.5 times approx.)
by not running them with datashard log batching enabled.

It is safe because tests with log batching discover less problems
than without ("glueing" transactions together eliminate chance of
something bad happen in between).

2 files changed, 7 insertions, 3 deletions

diff --git a/library/cpp/actors/testlib/test_runtime.cpp b/library/cpp/actors/testlib/test_runtime.cpp
index 06ad5d5353..9a5759b98a 100644
--- a/library/cpp/actors/testlib/test_runtime.cpp
+++ b/library/cpp/actors/testlib/test_runtime.cpp
@@ -663,10 +663,10 @@ namespace NActors {
 
         TInstant time = scheduledEvents.begin()->Deadline;
         while (!scheduledEvents.empty() && scheduledEvents.begin()->Deadline == time) {
-            static THashMap<std::pair<TActorId, TString>, ui64> eventTypes;
+//            static THashMap<std::pair<TActorId, TString>, ui64> eventTypes;
             auto& item = *scheduledEvents.begin();
             TString name = item.Event->GetBase() ? TypeName(*item.Event->GetBase()) : Sprintf("%08" PRIx32, item.Event->Type);
-            eventTypes[std::make_pair(item.Event->Recipient, name)]++;
+//            eventTypes[std::make_pair(item.Event->Recipient, name)]++;
             runtime.ScheduledCount++;
             if (runtime.ScheduledCount > runtime.ScheduledLimit) {
 //                TScheduledTreeItem root("Root");
diff --git a/ydb/core/tx/schemeshard/ut_helpers/test_env.cpp b/ydb/core/tx/schemeshard/ut_helpers/test_env.cpp
index f24b7bdfef..5759ec4d79 100644
--- a/ydb/core/tx/schemeshard/ut_helpers/test_env.cpp
+++ b/ydb/core/tx/schemeshard/ut_helpers/test_env.cpp
@@ -876,7 +876,11 @@ NSchemeShardUT_Private::TTestWithReboots::TTestWithReboots(bool killOnCommit, NS
 }
 
 void NSchemeShardUT_Private::TTestWithReboots::Run(std::function<void (TTestActorRuntime &, bool &)> testScenario) {
-    Run(testScenario, true);
+    //NOTE: Run testScenario only with (datashard) log batching disabled.
+    // It is safe because log batching could only hide problems by potentially "glueing"
+    // sequential transactions together and thus eliminating a chance of something bad happen
+    // in between those transactions. So running tests without log batching is more thorough.
+    // (Also tests run slightly faster without log batching).
     Run(testScenario, false);
 }