Toggle LogViewer scroll-locked! Your tests will be boosted

Today, I did an analysis how to make my test run faster. The objective was my code reads 1000 rows from CSV file using “Data-driven testing” feature, and my test just print all rows in the log. I implemented several patterns of implementation (test cases, test suites, keyword). The result was interesting — the slowest result was over 2 minutes 26 seconds. The fastest result was 0 minute 22 seconds. Quite a difference. I will write a report and disclose it here later.

Here I will tell you what surprised me today. The Log Viewer has Scroll Lock toggle button.

Log Viewer_Scroll Lock

I have never turned it “Locked” up until now. I happened to toggle it “Locked”. Then my tests were boosted!

If you “Lock” the Log Viewer, it stops auto scrolling. Effectively the Log Viewer becomes useless.

By “Scroll Lock” toggled Locked, my test got freed from the overhead of displaying verbose step execution logs. Instantaniously my test got boosted!

You can still see the test progress in the “Console”, or “Job Progress” modal.

3 Likes

That made my day, I think up to now is the most relevant conclusion!

1 Like

I guess, toggling the “Scroll Locked” button “Locked” has a similar (but a bit less) effect as disabling “Log executed test steps”.

“Project Setting > Execution > Log executed test steps Enabled/Disable” option was freely available in KS v6.x, but turned to be Enterprise feature at v7.0. Users of the Free version can not disable “logging executed test steps”. See the following post for the history.

Now I have found the Scroll Lock button, which is freely available to all in v7.x and v8.0, decreases the overhead of Log Viewer.
Scroll Lock

I am glad that I could find it.


I guess, turning “logging executed test steps” disabled will decrease more of CPU overhead than setting LogViewer with “Scroll Locked”.

I have ever read the source code of Katalon Studio to find out how it logs executed steps. See this for my findings. I found that, if the option is disabled, Katalon skips logging the “START” event and the “END” event of all lines of a Test Case script. No step-execution-logging event is fired.

On the other hand, in the case where the step-execution-logging is enabled but the LogViewer is Scroll-Locked, the step-execution-logs will be fired (hence consumes some amount of CPU/memory resources) but the logging events will be ignored by Log Viewer. You know, the GUI rendering process of Log Viewer with Scroll unlocked will consume a lot of CPU.

Toggling the Log Viewer “Scroll Locked” decreases much overhead, though less than disabling the “log executed steps”. Still I believe “Scroll Locked” will help the KS Free version users who want to run long-running-tests.


@Jass the product owner of Katalon Studio

Please do not change the “Scroll Lock” button to be an Enterprise feature.

Your tests are slowed down by Log Viewer! Log Viewer may force a test that can potentially finish in 22 seconds to take 2 min 26 sec, as my experiment tells. Users are not aware how much Log Viewer is disturbing us. They are too accustomed to the slow performance of tests in Katalon Studio. They just keep waiting for their tests to run hours and days. How unfortunate!

I do not need most of the information displayed in the Log Viewer. Does anybody want to read the timestamp of START of a command in a test case, the command literal in test case, timestamp of END? Nobody, I believe.

The only goodness is the error icon in red color

I have not read every word above, but in the other thread, I had thought to mention I never use tree mode in the Log Viewer, and only print Warnings, Failed and Error:

image

IOW, you may not need to lock the viewer.

this seems like something provided by the eclipse gtk framework himself.
i suppose, the way it work is, once activated it will block the widget displaying the new logs from being updated, once the current hight is filled.
therefore some savings in ram usage.
i doubt katalon will be able to make this an enterprise only feature but who knows.
good finding!

actualy, a sane developer may not need the log viewer at all. a sane console and a proper final report is more than enough

@Russ_Thomas

I know you are a wise man!

But I am afraid, most of Katalon users (including me) are not.


Recently I upgraded to Katalon Studio v8.2.0. Soon after updating, I checked how the Log Viewer is configured.

Log Viewer shows Tree View as default

The Log Viewer is configured to show the Tree View, rather than the Table View, as default. So, I guess, most of Katalon Users will leave it as it is. They may not be aware of the Table View at all.

Table View is configured to show All as default

I checked how the Table View is configured as default.

As you see, the Table View is configured to show All messages as default. I am sure, most of the Katalon users have the same setting.

Of course you can deselect All, and select Warning, Failed and Error. But you would change the settings only if you are aware of the implication to the tests performance. Most of the Katalon users are not.

“loading logs (XX%)” takes long time

I tried switching from the Table View to the Tree View. Something ridiculous I saw. When I toggled the button, LogViewer started “loading logs”. It took 62 seconds! I wanted to stop it, but I could not.

I believe that the LogViewer was reading a execution0.log file located in the Reports folder. In my case, the file had the size of 3.12 megabytes. The files was this big because I executed a long running test. I got irritated waiting for this loading to finish.


I suppose that the Katalon developers wanted to present the LogViewer as its full features. It resulted running tests slowly due to the processing overhead. How unfortunate!

I would do just the same as @Russ_Thomas does from now on.

@Jass

I hope that Katalon team to review the way how to present the Log Viewer.

I think the initial setting should be:

  1. show the Table View, not the Tree View
  2. in the Table View, do not select All. Select Warning, Failed and Error

in the hope that the users’ tests could run as fast as possible;

Not only in the Enterprise version, but in the Free version, tests should run fast.

I am not sure about this.
It may be true in the case of a test suite report, but i don’t find such file being created when i execute only a test case.
The detailed info from a test-case execution may be stored in a different place … and further aggregated with the data from execution0.log (although this file contains also a lot of data)
But yeah, looks like switching from table view to tree view is doing some log processing.
Have to dig more.

LE: I mean, I am not sure if only the data from this file is needed for log-viewer, or it is accumulated also in some other place.
The data from a given test-case seems to be accumulated in memory up to now, until i find other evidences.
So the question is … once flushed to execution0.log and rendered by the log viewer, it is released from the memory?

An example of execution0.log file:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE log SYSTEM "logger.dtd">
<log>
<record>
  <date>2021-11-21T18:42:48</date>
  <millis>1637487768056</millis>
  <sequence>0</sequence>
  <level>START</level>
  <class>com.kms.katalon.core.logging.XmlKeywordLogger</class>
  <method>startSuite</method>
  <thread>1</thread>
  <message>Start Test Suite : Test Suites/TS1</message>
  <nestedLevel>0</nestedLevel>
  <escapedJava>false</escapedJava>
  <property name="rerunTestFailImmediately">false</property>
  <property name="retryCount">0</property>
  <property name="name">TS1</property>
  <property name="description"></property>
  <property name="id">Test Suites/TS1</property>
</record>
...

Please find the name logger.dtd. This implies that this file is created by the Java Standard Logging framework. See

You are right. The detailed info is managed by the Java Logging framework somewhere, somehow during a Test Suite is running.

Once a Test Suite finished running, I suppose, Katalon Studio calls the framework API to serialise the detail log into execution0.log file. Then the Logging framework retrieved the detail log from somewhere and format it into an XML text file.

Yes, the heap memory is released, the garbage collection working fine, as far as I observed using VirtualVM tool.

Aha, so this may explain the log viewer behavior.
In tree view mode looks like it is rendering some ‘memory unfriendly’ widgets, compared with the table view which displays only text lines

Now, I have to find a tweak to close the log-viewer completely in free version :smiley:

Yesterday, I happened to erase the Log Viewer somehow. With having no Log Viewer in GUI, I started a Test Suite. Then Katalon Studio got frozen. Poor guy! Katalon Studio can not live without it.

1 Like

Most probably, under the hood, the log viewer it is using something like:
https://python-gtk-3-tutorial.readthedocs.io/en/latest/treeview.html#the-view

HA!
I managed to turn it off.
Right click on the tab, Detach and close the window.
Now I run my suite only with console :smiley:
detach

Of-course, after I close Katalon and open it again, Log Viewer is back … but at least it didn’t freeze.
Well, I have only one testcase in a suite, but worth to try with larger suites, provided won’t crash, and compare the memory usage.

Yes, I tried detaching the Log Viewer. I found, I could even close the detached window.

I had a Test Suite with Log Viewer in Tree mode, which ran in 5 min 37 seconds.

When I detached the Log Viewer and closed it, the same Test Suite ran in 0 min 25 seconds.

10 times and more faster!

This difference is ridiculous.

1 Like

May be I am wrong. Possibly the test suite was running silently, and I just missed any sign of progress.

You should see some activity in the console and in the ‘job progress’.
Or could be it was a corner-case and it actually crashed, we know sometime Katalon has strange glitches and once restarted is fine again.

Cool. :sunglasses:

Upgrades – no upgrade has ever changed the setting, for me.

Table view? I call it log view if I need to name it. It’s kind of a filtered log view, if anything. I just wish I could make suite logs do the same thing:

image