locked
Performance - Why VB is so much slower than C++ RRS feed

  • General discussion

  • I am a VB advocate but I find that C++ is blindingly fast compared to VB on the same machine, that takes care of John Weins questions regarding caching. You see I've asked this question before and have yet to get an acceptable answer.

    Let me pick a task to remove us from the theoretical:File Search: I have a search task written in presumably in C++ and one I wrote in VB. There is no comparison. The C++ search will complete hours before the VB and the disc I ran it on is not that large. It's a 20GB disk with about 7GB used.

    Quanta did add something I hadn't considered"

    "Well, VB.NET is managed code and it is the answer, if rather vague and broad.  I would suspect that the simple act of marshalling data through various layers and into various different structures is what swallows the extra CPU cycles"

    But it's still vague.

    From an article (http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET):

    "...Technical fellows at Microsoft (highest technical position in the company!) say that .NET is not conducive to system programming"

    That's what I do is systems programming.


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    Wednesday, June 20, 2012 12:05 AM

All replies

  • It all just depends on what you're doing.

    There is overhead to executing managed code - for most programming, the overhead is minimal.  In fact, there are many cases where managed code can actually execute faster than the equivalent C++ code.  Typically, the performance differences are due to differences in libraries, techniques, etc.

    That being said, the C++ compiler does do a lot more optimization (even more than the C#/VB.Net compilers + JIT combined), and is less abstracted, which means you can typically, with enough effort, write C++ code that is faster than the equivalent managed code.  Doing so typically takes more developer time and effort, is more prone to bugs, etc - but can be done.

    Most of the time, though - the bulk of the operational time of an algorithm is tied up in a very, very small percentage of the code.  One major advantage managed code has is the tooling - there is a lot of tooling available for profiling managed code that is incredibly powerful and easy to use.  This often means that it's easy to find the problematic areas of managed code, and correct them - which is part of why .NET code is often just as fast (and often faster) than native code.

    However, if you take the time to do the work, chances are you can make things faster with native code.  This is especially true with heavy computational code, since you often can do things like use SSE intrinsics, use new features like C++ AMP to target the GPU, etc, and squeeze out huge amounts of computation.  Debugging and development time suffer, but for systems programming, it's often worth it.

    That being said - I often find that a mix is the "best of both".  You can take advantage of VB or C# for most development, profile it, and rewrite any critical portions of the code in C++ to squeeze every bit of performance out of those routines.  Many large scale applications work this way - the GUI layer is often managed code, but the core routines are calling into native code...


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Wednesday, June 20, 2012 12:17 AM
  • Thank you Reed.

    What can I do to convince you that there is a problem or at least I have one. here's my code. I don't think there are any problems.

    By the way I have tried profiling and profiling says that all the ti me is taken up by the richtextboxx.  ( the code you see uses a list view)

    By the way,I am used to VAX and bliss which has a seven pass compiler!

    <MTAThread()> _

        Private Sub Search(ByVal WD As fileScn)

            'This subroutine is for searching a single file at a time but it is and needs to be multithreaded

            ' Search does fileoutput to Form1.OutPut or by invoking LV1

            'Sample is the compared Entity to a standard, Filespec is what the label says.

            'A byte by byte search has been employed because I really wanted to search the file as opposed to using an algorith

            Dim SearchTarget As Char() = WD.SearchStr                           ' Char version of SearchStr (string)

            Dim Filespec As String = WD.path                                    ' Path

            Dim Dir As String = Filespec.Substring(0, Filespec.LastIndexOf("\")) ' Directory

            Static OldDir As String

            Dim filelen As UInt64 = WD.SearchStrlen

            Dim file As String = Filespec.Substring(Filespec.LastIndexOf("\") + 1)

            Dim I As UInt32 = 0

            Dim II As Int32 : II = 0

            Dim NewDir As Boolean = True

            Dim lst As New List(Of ListViewItem)                                ' Empty list of listviewitem

            Dim Tab As String = "        "

            Dim NewPath As Boolean = True

            Dim OldPath As String = String.Empty : Dim Path As String = String.Empty

            Dim fsIn As FileStream = Nothing

            Common.PD.Files += 1                                                    ' Increment Files

            With WD

                .lst = New List(Of ListViewItem)                                    ' Initialize the list

                .SearchStrlen = SearchTarget.Length - 1

                .Func = .Func And Not Func_Newpath

                .Func = .Func And Not Func_Directory

                F1 = Forms()

                For .I = 0 To .SearchStrlen

                    .SearchString += .SearchStr(.I)   ' Read in search word or phrase in Characters into a string

                Next

                If .Buf = Nothing Then Return

                If (Dir.Length + 1 + file.Length) < 70 Then

                    F1.Invoke(F1.FormDelegate, New Object() {Dir + "\" + file})

                Else

                    F1.Invoke(F1.FormDelegate, New Object() {file})

                End If

                'The following are judged to require context: WD, WD.II, WD.I Searchstring length is derived each time through

                If (.Buf.Length > 0) Then

                    ' The following code is the Search section of the file

                    For .I = 0 To .Buf.length - 1

                        If (.Buf(.I) = SearchTarget(.II)) Then      ' If Input is equal to Searchpattern - Criterion Met

                            If .II = .StringLength Then             ' Criterion has been reached-II will keep count of matching characters

                                .Offset = .I - .StringLength        ' WD.Searchlength = length-1 for starting count for 0, inclusive

                                ' Offset = the offset into the byte array holding data

                                ' Dim item1 As ListViewItem = New ListViewItem(Hex(Offset))   ' Hex as offset if desired

                                If .Func And Func_file Then

                                    If NewPath Then : F1.Invoke(F1.TheDelegate, New Object() {Path}) : NewPath = False : End If  ' Only Display directories with contents

                                    If WFD.cFileName.Length > ResultingStringLen Then WFD.cFileName = WFD.cFileName.Substring(0, ResultingStringLen) 'ResultingStringLen)

                                    Static createDate As Date

                                    createDate = Common.CreateDateFromFileTime(WFD.ftCreationTime)

                                    ' Add offset and Contents  to list

                                    Dim SearchedObject As String = Common.space + CStr(.I) + Tab + .Buf.Substring(.Offset, Math.Min(cdispStringLen, .Buf.length - .Offset - .SearchStrlen)) + Common.space + Format(createDate, "d") _

                                                                 + "     " + (Common.PrintObjectByteSize(filelen))

                                    .lst.Add(New ListViewItem(SearchedObject))

                                    SearchedObject = Nothing

                                Else ' Therefore Search

                                    If (Not (Func_Newpath And .Func) = Func_Newpath) Then ' Latch

                                        ' Some close explanation and documentation is required. See the documentation directory.

                                        .lst.Add(New ListViewItem(Dir))

                                        Dim FOI As ListViewItem = New ListViewItem(.path.Substring(Filespec.LastIndexOf("\") + 1))  ' Write to the list

                                        .lst.Add(FOI)                                           ' Add the filename of Interest to the new list

                                        .Func = .Func Or Func_Newpath                           ' Latch it

                                        FOI = Nothing                                           ' Clear LVI

                                    End If '

                                    Dim Founditem As ListViewItem = New ListViewItem(.Offset)   ' Decimal as offset<<<<<<<<<<<<<<<<<<

                                    If (.Buf.length - .Offset - .SearchStrlen) < (.Buf.length - .Offset) Then .SearchStrlen = 0

                                    Static Num As Integer

                                    Num = Math.Min(cdispStringLen, .Buf.length - .Offset - .SearchStrlen)

                                    Founditem.SubItems.Add(.Buf.Substring(.Offset, Num))

                                    .lst.Add(Founditem)                               ' Add item to list

                                    Founditem = Nothing

                                    'I += Num

                                End If      ' If WD.Func And Func_Search

                                .II = -1    ' Slight dance for next step

                            End If          ' If WD.II = SearchLen Then

                            .II += 1        ' Add 1 -Also set's -1 to 0

                        Else

                            .II = 0         ' It isn't equal - Reset

                        End If              ' If Wd.Buf(WD.I) = SearchTarget(WD.II)

                    Next                    ' For WD.I = 0 To (WD.Buf.Length - 1)

                End If                      ' If (WD.Buf.Length > 0) Then

                If .lst.Count > 2 Then ' Delegate it

                    F1.Invoke(F1.AddTolvDelegate, New Object() {.lst}) ' Write search list

                End If

                .Buf = String.Empty

            End With ' WD

            WD = Nothing

            GC.Collect()

            Interlocked.Decrement(threadCounter)

            F1.Invoke(F1.WrtoTB5Del, New Object() {Common.PD}) ' End of list

            Dim AvailThreads As Integer = 0

            ' Finding out when you processed the last thread is difficult with multiprocessing

            ' this thread was originally tuned using an SSD and a dual processoe Extreme. This thread may

            ' require localized tuning but I doubt it.

            If Common.threadCounter <= 1 Then 'Counter for when to write

                ' F1.Invoke(F1.WrtoTB4Del, New Object() {Common.threadCounter - 1})

                Form1.EndOfRequest(Common.PD)

            End If

            If OldDir <> Dir Then

                OldDir = Dir

                Interlocked.Increment(Common.PD.Dirs)

            End If

            F1.Invoke(F1.WrtoTB5Del, New Object() {Common.PD})

            Return

        End Sub


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, June 20, 2012 12:37 AM
  • "There is overhead to executing managed code - for most programming, the overhead is minimal.  In fact, there are many cases where managed code can actually execute faster than the equivalent C++ code.  Typically, the performance differences are due to differences in libraries, techniques, etc."

    Ok above I've give an actual search routine in VB. It it very slow. It does a character by character search-there are no algorithms employed, which in itself may be a problem..

    I don't believe they are any problems but I'm willing to be wrong.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    Wednesday, June 20, 2012 12:52 AM
  • There's too much code here to really follow - but, looking at it, this doesn't surprise me:

    "By the way I have tried profiling and profiling says that all the ti me is taken up by the richtextboxx.  ( the code you see uses a list view)"

    While I can't really say much, as the profiling wasn't done against this code, I'd suspect that the majority of this code would be tied up waiting for the marshalling back to the UI thread via all of the Invoke calls.  This is probably why you get abysmal performance, and would most likely be helped tremendously by batching your UI updates and handling them asynchronously instead of having so many blocking Invoke calls scattered through the code.

    That being said, it's not very easy to follow code - so its tough to know exactly what's happening.  I do see a lot of searching, but the code's very highly coupled.

    Just by looking, I'd focus on refactoring the code first.  There's a lot of coupling between the logic and the presentation here, which makes it VERY tough to really get to the core of why things are slow, and makes it even more difficult to optimize.  I'd start by cleaning up a lot of the file handling (the System.IO namespace really is nicer, and more reliable, than string parsing for this).  While huge amounts of code are left out, it does look like something that would benefit highly from a pipelining or a producer/consumer approach, especially when you take the comments about multithreading into account...



    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Wednesday, June 20, 2012 12:53 AM
  • Hmmm, actually what you say makes sense.

    "the System.IO namespace really is nicer, and more reliable, than string parsing for this"

    Which routines....It's highly coupled because it's supposed to be optimized.

    Thank you darnold.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, June 20, 2012 1:10 AM
  • Hmmm, actually what you say makes sense.

    "the System.IO namespace really is nicer, and more reliable, than string parsing for this"

    Which routines....It's highly coupled because it's supposed to be optimized.

    Thank you darnold.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Coupling != optimized.  In fact, tight coupling often leads to an inability to optimize properly, since it's very difficult to extract out the appropriate portions and optimize them fully.

    In this case, it's not really possible to help you completely because so much is "hidden" in the implementation of fileScn (and passed in), so we can't see what's really happening.

    As for the System.IO namespace - things like this:

    Dim Dir As String = Filespec.Substring(0, Filespec.LastIndexOf("\")) ' Directory

    Would be easier written as:

    Dim Dir As String = System.IO.Path.GetDirectoryName(Filespec) ' Directory

    (It's also far easier to follow what's going on...)


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Wednesday, June 20, 2012 1:16 AM
  • I'm curious. When optimizing my own code, I sometimes look at the resulting native code to see what it's actually doing.
    Tried to add the missing types/members (just pseudo for making it compilable), but failed due to inconsistenet types. As you don't have Option Strict On it's hard to make any statement about performance. Anyway tried to make it compile but it was too much to do.

    One thing I see is that you're calling F1.Invoke. If F1 is a Form, the call blocks and keeps the worker from going on. If you have work result to present in the UI, I'd make the worker push it into a container (list/queue) and pull it from there in the UI timer based in junks so that it keeps responding.

    I can not really evaluate what else is going on.

    EDIT: Ok, you seem to collect the result in the "lst" field.


    Armin


    Wednesday, June 20, 2012 1:19 AM
  • I don't think the problem relates  to the invokes because search words with practically no 'hits' or finds are still very slow. Eventually it will find the possibilties but most 'eventually'.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    Wednesday, June 20, 2012 1:23 AM
  • I don't think the problem relates  to the invokes because search words with practically no 'hits' or finds are still very slow. Eventually it will find the possibilties but most 'eventually'.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    I'd be curious - if you profile this in a situation without many hits, what's taking up the processing time?


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Wednesday, June 20, 2012 1:47 AM
  • Just for information;

    http://www.osnews.com/story/5602/Nine_Language_Performance_Round-up_Benchmarking_Math_File_I_O/page3/


    You've taught me everything I know but not everything you know.

    Wednesday, June 20, 2012 3:29 AM
  • Mr. Monkeyboy,

    I'm afraid that's invalid for at leat 2 reasons.

    First he compared all managed languages even C++ and I am saying that managed languages are way slow. Secondly that was a 2003 article making at it nine years old. That makes any comparison apples-and oranges.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    Wednesday, June 20, 2012 3:57 AM
  • Neil,

    I nolonger have the profiler...so I'd better not fictiously answer the question.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, June 20, 2012 4:19 AM
  • Armin,

    With the exception that Reed (Copsey) assumes that meant is C++ unmanaged, I completely agree with Reed in his first reply, C++ (not managed) will be in some cases perform faster then VB. 

    Moreover, Intel Assembler will do it in some cases much faster then C++. 

    But for both not in business tools (or likewise), those are to complex to solve with the tools above to keep them maintainable so there will be many overlaps for example in error preventing which can and is done in VB in optimized methods.

    The lower you are at machine level the more chance you have Intel Assembler will perform the best. 

    For instance a program to set one byte into the video adapter.

    This is of course not the case for C++ managed.

    I know you knew this, but I addressed this to you because I started it as a reply to you and would have  to change things otherwise  :-)


    Success
    Cor


    Wednesday, June 20, 2012 7:28 AM
  • Cor,

    I have an old search program that I assume is written in C++ unmanaged and the one you see the code for...yes with the invokes that microsoft designed threads with in managed code.(It's poor design).  the search program is at least 200 times faster on managed code shown above with very few hits.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, June 20, 2012 8:55 AM
  • Renee,

    I'm not surprised but there is a chance I've warned when you started to do it in managed code.

    The threads by the way will be replaced (not really, they stay of course for backward compatibility) by real code syntax in VB and C#, Microsoft probably knows that it was not the best thing they made in past.

    http://msdn.microsoft.com/en-us/library/hh191443(v=VS.110).aspx

    It is the most important addition to the program languages VB and C# for version 2012 (be aware Metro is an addition to Visual Studio 2012, not direct to the program languages but usable by the program languages).


    Success
    Cor


    Wednesday, June 20, 2012 9:19 AM
  • Just an example:

    I wanted to process a Bitmap. It wasn't meant for speed, so I used GetPixel/SetPixel (from VB).

    In practice, it turned out to be too slow. I knew that direct pixel access using LockBits/UnLockBits would be much quicker, so I did it and was not disappointed.

    But as I'm a friend of optimizations (and curious), I wondered: How quick is it in unsafe C# using pointers? I don't have the numbers anymore, but it was again a lot quicker.

    Next attempt: Doing it in unmanaged C++. Even with all optimizations, the surprise was that I couldn't make it work as quickly as the unsafe C# solution.

    What's missing? Right, I did it in Assembler (using __asm blocks in C++). Well, umm, it was much slower. :-) But this only tells me that I'm not really experienced in writing optimized assembler code. lol So it's better to leave it up to a compiler.

    The message of this message is the great optimization of the compiler for unsafe C# blocks. How it made use of MMX and other advanced registers was impressing. This is just an example and can vary of course, but it's also true.


    Armin


    • Edited by Armin Zingler Wednesday, June 20, 2012 12:14 PM spelling
    Wednesday, June 20, 2012 12:14 PM
  • Any significant difference in speed (in the absence of caching) is probably due to a difference in algorithms.  A character by character string search is the slowest search algorithm.
    Wednesday, June 20, 2012 2:30 PM
  • Hi Renee,

    Since you are interested in improving the performance, I am curious as to why you are performing this string copy in this manner?  
    Maybe I am misunderstanding as I do not know how "fileScn" is defined, especially "fileScn.SearchStr").

    For .I = 0 To .SearchStrlen
        .SearchString += .SearchStr(.I)   ' Read in search word or phrase in Characters into a string
    Next

    Concatenating  strings in .Net involves array allocation and copying for each string sequence added.
    If fileScn.SearchStr is just a string, then this should be much faster:

       .SearchString = New String(.SearchStr,0, .SearchStrlen + 1)

    Side Note:  In your loop, do you really intend to do the loop from zero to .SearchStrlen versus zero to .SearchStrlen - 1 ?

    If fileScn.SearchStr is a array (list?) of strings to add, then using a System.Text.StringBuilder may be a better option.

    You stated: "By the way I have tried profiling and profiling says that all the time is taken up by the richtextboxx."

    This may or may not be of value to you, but I have found that when appending a lot of text to a richtextbox, that it is beneficial to disable it's redraw until all strings are appended.  This snippet demonstrates this.

    Public Class Form1
       Private sw As New Diagnostics.Stopwatch
    
       Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
          RichTextBox1.Clear() : RichTextBox1.Refresh()
          sw.Reset() : sw.Start()
          addtext()
          sw.Stop()
          Label1.Text = sw.ElapsedMilliseconds.ToString
       End Sub
    
       Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
          RichTextBox1.Clear() : RichTextBox1.Refresh()
          sw.Reset() : sw.Start()
          RedrawContol.AllowRedraw(RichTextBox1, False)
          addtext()
          RedrawContol.AllowRedraw(RichTextBox1)
          sw.Stop()
          Label2.Text = sw.ElapsedMilliseconds.ToString
       End Sub
    
       Sub addtext()
          For i As Int32 = 0 To 10000
             RichTextBox1.AppendText(i.ToString & vbCr)
          Next
       End Sub
    End Class
    Module RedrawContol
       <Runtime.InteropServices.DllImport("user32.dll", SetLastError:=True, CharSet:=Runtime.InteropServices.CharSet.Auto)> _
       Friend Function SendMessage(ByVal hWnd As IntPtr, ByVal Msg As Int32, ByVal wParam As IntPtr, ByVal lParam As IntPtr) As UInt32
       End Function
    
       Friend Const WM_SETREDRAW As Int32 = &HB
    
       Public Sub AllowRedraw(ByVal cntrl As Control, Optional ByVal allow As Boolean = True)
          If allow Then
             SendMessage(cntrl.Handle, WM_SETREDRAW, New IntPtr(1), IntPtr.Zero)
             cntrl.Invalidate()
          Else
             SendMessage(cntrl.Handle, WM_SETREDRAW, IntPtr.Zero, IntPtr.Zero)
          End If
       End Sub
    End Module




    Wednesday, June 20, 2012 3:00 PM

  • The threads by the way will be replaced (not really, they stay of course for backward compatibility) by real code syntax in VB and C#, Microsoft probably knows that it was not the best thing they made in past.

    http://msdn.microsoft.com/en-us/library/hh191443(v=VS.110).aspx



    Cor -

    Async/Await doesn't replace threads as much as they replace or update asynchronous operations.  This can be used for task based threaded algorithms, but really doesn't replace threading in general in any meaningful way.  Data parallelism (and even composable task parallelism) was handled very cleanly in .NET 4 with the TPL, and task parallelism and pipelining are getting huge improvements in .NET 4.5 via TPL Dataflow...

    (I do think this is a killer feature, and will replace a lot of people's need for self-managed threading - but really for things more like BackgroundWorker, not for data parallel operations like Renee's)

    -Reed


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".

    Wednesday, June 20, 2012 3:21 PM
  • I agree John,

    But I didn't know anyother algorithmd. I should have picked up knuth or someone.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, June 20, 2012 3:42 PM
  • Tintnman,

    You asked a number of good questions and you may have found an error although it wont make an appreciable difference. I haven't been to sleep last night and I want to take a look at the code when Im in better shape.

    AND you have touched a very valuable area which is that of the rich text box. However this is from Filescan which uses a listview. I have several projects going and I fear I may have mislead you.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me



    Wednesday, June 20, 2012 3:46 PM
  • Yes!!!  I agree.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, June 20, 2012 3:56 PM

  • Async/Await doesn't replace threads as much as they replace or update asynchronous operations.  This can be used for task based threaded algorithms, but really doesn't replace threading in general in any meaningful way.  Data parallelism (and even composable task parallelism) was handled very cleanly in .NET 4 with the TPL, and task parallelism and pipelining are getting huge improvements in .NET 4.5 via TPL Dataflow...

    (I do think this is a killer feature, and will replace a lot of people's need for self-managed threading - but really for things more like BackgroundWorker, not for data parallel operations like Renee's)


    Reed,

    http://en.wikipedia.org/wiki/Parallel_computing

    I thought this above in the link came nearby for microcomputers, but just some simple steps 

    But I thought the starts are C++ and it would take still years to go.

    Be aware I think and have in my idea that more times written is what Renee have done in VB not something you would not want to do in VB (or let us say managed code).



    Success
    Cor


    Wednesday, June 20, 2012 4:21 PM
  • Just FYI:

    I just ran a simple test and wrote a single sentence to a textbox and a richtextbox 100k times in the IDE.  The textbox took less than 0.5 seconds and the richtextbox took over 12.7 seconds.  So there is a pretty big difference in the two.  No appending just resetting the .text.

    Brian

    Wednesday, June 20, 2012 4:57 PM
  • Did you use appendtext? Much is being left unspecified here.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, June 20, 2012 6:11 PM
  • Would you clarify the english Cor"?

    Rrenee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, June 20, 2012 6:13 PM
  • If you don't set the listview to begin updates and then perform a number of item changes you will experience the same problem as with the richtextbox where every modification to the control contents wastes time with needless redraws of the user control.

    I'd say that the others have already listed the main problems with the speed:  too many invokes, too much string creation, and too much direct GUI interaction.  If those invoke calls are spinning up new threads to run this same routine on a new path then you may have a threading issue also causing problems.  I don't see anything more than a thread count variable to manage running threads so its not clear if there is a thread manager process of if this code just spins up a new thread for every path it tries to search.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Wednesday, June 20, 2012 6:33 PM
  • The update of the UI shouldn't have to be considered.  Typicallly searching a drive for a string won't return many matches and updating the UI thread doesn't affect the speed of the search which is done on background threads.  Searching 100's of Gigabytes for a typical 20 character string is going to take time.  It's up to the user to narrow the search to file types and locations in whch she whould like to find the string.
    Wednesday, June 20, 2012 7:32 PM
  • John,

    It shouldnt take as long as it taking. There only about 7 gb of disk and it's hours.

    To be honest Im fed up with the Windows operating system.It gotten away from programmingand is now in "pretty pictures", which I just dont care about. But let me get into specifics.

    Microsoft made engineering decisions about there Easy-to-use" and relatively easy to program operating system operating system. And there are constructs about the operating system. Threads well all agree are real. But forground back groung is MS's way of explining how to program this system. I've come to the conclusion that grahics are just icing on the cake or fuzz. They are totally unecessary at least to me the are. I was programming and happy at it for 20 years and then Windows came along. But things have grown far less technical. Tom's hardware is barely recognizable and is full of commercial garbage. 

    I think I'll return to Vaxes and Bliss. Anything to get to a real OS. I'll be around.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me


    Wednesday, June 20, 2012 7:58 PM
  • "It shouldnt take as long as it taking. There only about 7 gb of disk and it's hours."

    I primarily search the Reference Source for 10 to 20 character strings.  It typically takes 3 to 7 minutes to search 5.5 GB without restrictions on file type.

    Don't know what happened.  At one time our code performed approxmately the same.

    Wednesday, June 20, 2012 8:31 PM
  • Well I've been hit and run by an illegal alien. I was was quite honest in what I said. FLUFF was the word I was Looking for!!! I'll see you later.

    By the way I deliberately wrote this to do byte for byte comparisons. I wanted something husky. None of this algorithmic stuff. I rue that decison now.

    Renee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Wednesday, June 20, 2012 8:44 PM
  • The update of the UI shouldn't have to be considered.  Typicallly searching a drive for a string won't return many matches and updating the UI thread doesn't affect the speed of the search which is done on background threads.  Searching 100's of Gigabytes for a typical 20 character string is going to take time.  It's up to the user to narrow the search to file types and locations in whch she whould like to find the string.

    If there are not many updates to the listview, then you are correct that there will be little to no difference with or without a call to BeginUpdate.  But if there are many updates then the method call could make a substantial difference in execution time.  Since the nature of this kind of routine cannot know the number of results it would be best to call BeginUpdate.

    The calls to Invoke are synchronous so they do halt the progress of the background thread until they complete.  If the code were using BeginInvoke and handling the UI updates via async then the background code could continue; though you may then run the risk of flooding the UI with calls to update.  So rather than updating the UI here and there based on conditions it would probably be better to build up a series of updates and apply them all at once.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Wednesday, June 20, 2012 9:11 PM
  • The update of the UI shouldn't have to be considered.  Typicallly searching a drive for a string won't return many matches and updating the UI thread doesn't affect the speed of the search which is done on background threads.  Searching 100's of Gigabytes for a typical 20 character string is going to take time.  It's up to the user to narrow the search to file types and locations in whch she whould like to find the string.

    If there are not many updates to the listview, then you are correct that there will be little to no difference with or without a call to BeginUpdate.  But if there are many updates then the method call could make a substantial difference in execution time.  Since the nature of this kind of routine cannot know the number of results it would be best to call BeginUpdate.

    The calls to Invoke are synchronous so they do halt the progress of the background thread until they complete.  If the code were using BeginInvoke and handling the UI updates via async then the background code could continue; though you may then run the risk of flooding the UI with calls to update.  So rather than updating the UI here and there based on conditions it would probably be better to build up a series of updates and apply them all at once.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    Updating the UI thread without interferring with the search is trivial. At least it is using BackgroundWorkers which update in the completed event with Cores-1 workers running at all times during a search. It can appear that the UI hangs if Cores are used and the user doesn't use the keyboard or mouse for a while, because the OS will allocate most resources to the search. Updating the UI every few seconds in a long search is adequate and uses infinitesimal resources.
    Wednesday, June 20, 2012 9:25 PM
  • Would you clarify the english Cor"?

    Rrenee


    "MODERN PROGRAMMING is deficient in elementary ways BECAUSE of problems INTRODUCED by MODERN PROGRAMMING." Me

    Renee,

    Thanks, my text was not only unreadable in English (but you Americans use that for text as a synonym), it was unreadable in every language which I know. I changed it, I hope it clarifies a little bit what I wanted to say. The subject is difficult because it assumes that you know (the mainlines) about this new support in Intel processor improvement.

    http://software.intel.com/en-us/blogs/2009/08/31/why-parallel-processing-why-now-what-about-my-legacy-code/

    Be aware this is not (only) about hyper threading but about newer features in the I7 processor and also it is still outside my current scoop as well.


    Success
    Cor

    Thursday, June 21, 2012 6:01 AM