Skip to content
This repository was archived by the owner on Feb 20, 2024. It is now read-only.

Speedup memorydump #18

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Speedup memorydump #18

wants to merge 1 commit into from

Conversation

MicroSourceCode
Copy link

Replacing the m_pText->clear() function with the replace function, it works faster. Replace 2 appendText calls with one writeText call, speed up when outputting bytes greater than 512, writeText is faster.

Replacing the m_pText->clear() function with the replace function, it works faster. Replace 2 appendText calls with one writeText call, speed up when outputting bytes greater than 512, writeText is faster.
@obfuscated
Copy link
Owner

Can you provide any measurements before/after? You can use the wxStopWatch class.

@MicroSourceCode
Copy link
Author

MicroSourceCode commented Mar 6, 2021 via email

@MicroSourceCode
Copy link
Author

MicroSourceCode commented Mar 7, 2021 via email

@obfuscated
Copy link
Owner

And the units are?

@MicroSourceCode
Copy link
Author

In seconds, but I doubt it. WriteText is faster because it does not move the cursor to the end.
WriteText: 0.000029586 Single line output
ExpandText: 0.000030745 Single line output
Overall if block speed: if (m_ByteCounter != 0 && m_ByteCounter % 16 == 0)
old: 0.000050524
new 0.000031741

@obfuscated
Copy link
Owner

If these are in seconds, this means that this optimization doesn't matter in the real world.
Are you able to see visible difference between the two implementations?

@MicroSourceCode
Copy link
Author

There is no particular difference, but replacing AppendText with WriteText fixed the wxwidget 3.0.4 memory leak on my system. The debugger has stopped slowing down.

@MicroSourceCode
Copy link
Author

I will try to test the program on the wxwidget version 3.0.5, maybe the error has already been fixed.

@MicroSourceCode
Copy link
Author

Still, there is a gain in speed, all of the above referred to one line of output, except for the Replace and ChangeValue functions, but there are much more lines, so I see an increase in performance.

@obfuscated
Copy link
Owner

Can you measure it? I guess you can use wxStopWatch around the callers of AddHexByte. But if this change is improving performance then a change in the API would lead to a bigger change.

@MicroSourceCode
Copy link
Author

MicroSourceCode commented Mar 9, 2021

I did some research and I figured out what was going on. inserted the call to start the timer into the Begin function and the time display function into the End function. The Begin function starts wxTextCtrl at the beginning of the fill cycle, and the End function runs after it has filled. My changes give a decrease in time from 18 ms to 12 ms, but this is not particularly important. The program slows down dramatically when using the AppendText function, I pressed the Go button in the Memory window thirty times and wxTextCtrl slowed down dramatically, its running time increased from 1 second to 4 seconds when outputting 4096 bytes, but the program output time remained the same 12-18 milliseconds! The WriteText function bypassed a bug in wxWidget 3.0.4, the same behavior observed when using wxWidget 3.0.6.

@MicroSourceCode
Copy link
Author

I compiled wxwidget 3.0.6 with only gtk2 support, performance improved, the AppendText function began to work much better, but the fill cycle time began to gradually increase from 12 to 100 ms, this indicates that gtk3 uses a buffer for its elements and only then outputs data.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants