Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compact.AppendOutputText is very slow #70

Closed
Nukepayload2 opened this issue Oct 18, 2017 · 9 comments
Closed

Compact.AppendOutputText is very slow #70

Nukepayload2 opened this issue Oct 18, 2017 · 9 comments

Comments

@Nukepayload2
Copy link

Compact.AppendOutputText(String) encumbers performance when compacting a folder which has large number of files inside. The longer console output, the more execution time of Compact.AppendOutputText(String).
Consider replacing conOut with a virtualizing control such as ListBox to make this program faster.

@Nukepayload2
Copy link
Author

Nukepayload2 commented Oct 18, 2017

Use ListBox:

    Private Sub AppendOutputText(ByVal text As String)    'Attach output to the embedded console
        Try
            If conOut.InvokeRequired Then
                Dim serverOutDelegate As New AppendOutputTextDelegate(AddressOf AppendOutputText)
                Me.Invoke(serverOutDelegate, text)
            Else
                If text <> vbCrLf Then
                    conOut.Items.Insert(0, text)
                End If
            End If
        Catch ex As Exception
        End Try
    End Sub

@Iridium-IO
Copy link
Member

Iridium-IO commented Oct 18, 2017

Just wondering how much of a hit there is, and what sort it is (RAM, CPU)? Just curious, as the richtextbox is easier to use.

EDIT: Never mind, damn that's a huge hit, there's no way of knowing this was happening outside of actually testing them both 😮

@RebelliousX
Copy link

@Nukepayload2 And pass text as reference please.
Indeed, current behavior seems too slow. RichTextBox is not suitable for continuous logging.

@Iridium-IO
Copy link
Member

Iridium-IO commented Oct 18, 2017

I've been running performance tests using the Query compact option, rather than actually compressing and decompressing files over time. The difference is that when querying, it does so in quiet mode = only listing directories, not each file, so the performance hit wasn't noticed.

I'm implementing this now :)

@RebelliousX what do you mean by "pass text as reference"?

@RebelliousX
Copy link

RebelliousX commented Oct 19, 2017

@ImminentFate Jus noticed the function that @Nukepayload2 posted above, the String argument is passed by value ByVal not by reference ByRef. When passing by value, lots of copying of memory blocks will happen. I have a deeply nested folder that contains over 70 thousand files, only 8GB, it takes forever to compress using this app.

Plus try to run concurrent and multiple compact.exe to compress multiple files at the same time.

@Nukepayload2
Copy link
Author

@RebelliousX String is not System.ValueType. It's a reference type.
http://referencesource.microsoft.com/#mscorlib/system/string.cs,8281103e6f23cb5c

@RebelliousX
Copy link

Correct, but the passing of the the parameter text is ByVal not ByRef.

I use C++ mainly. But last time I used VB.Net was 5 years ago in college, so I could be wrong. But I think it won't hurt to make it by reference (it could improve performance too).

@Iridium-IO
Copy link
Member

I tested it just now, the difference between using a richtextbox vs a listbox is massive, but I can't detect any changes between ByVal and ByRef, so I'll probably just leave it as is for now

@Nukepayload2
Copy link
Author

@RebelliousX
String in VB.Net will be compiled to STRINGREF in native code.
STRINGREF is REF<StringObject> (see object.h line 1065.).
Defined in object.h line 1118, StringObject contains a DWORD and a pointer.
ByRef String in VB.net compiles to REF<StringObject>&. If you don't want to change the value of a string, passing REF<StringObject>& is a waste of memory.

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

No branches or pull requests

3 participants