Results 1 to 35 of 35

Thread: DoEvents and Performance

  1. #1

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    DoEvents and Performance

    In another thread:
    http://www.vbforums.com/showthread.p...aking-too-long

    a topic came up, which to me is an "urban myth" - but some people seem to believe strongly in the "large impacts the VB-DoEvents-call has on Performance" ...

    So, let's see what we will find.
    First some TestCode (always a good idea when you claim something, to pad it with some code):

    Paste it into a Form - for VB6 no control-placement is needed, just click the Form for repeated timings...
    Code:
    Private Sub Form_Click()
    Dim i As Long, T As Single, Pos As Long, Text1 As TextBox
    
    Const LoopCount& = 10 ^ 6, SmallerLoopCount& = 1000
    
    If Controls.Count = 0 Then Controls.Add "VB.TextBox", "Text1"
    Set Text1 = Me!Text1
    Text1.Visible = True
    
    ScaleMode = vbPixels: Cls: CurrentY = 40
    
    'first checking the average Call-Overhead of DoEvents (performing in the Sub micro-second (not milli-second)range)
    T = Timer
      For i = 1 To LoopCount
         DoEvents
      Next i
    Debug.Print "avg. Call-Overhead of DoEvents: "; Format((Timer - T) * 10 ^ 6 / LoopCount, "0.0µsec")
    
    'same thing (with the same LoopCount of 1Mio) for the VB-Instr-function in a typical "smaller string check"-setup
    T = Timer
      For i = 1 To LoopCount
         Pos = InStr(1, "SomeStringToCheck", "to", vbTextCompare)
      Next i
    Debug.Print "avg. Call-Overhead of InStr(): "; Format((Timer - T) * 10 ^ 6 / LoopCount, "0.0µsec")
    
    
    'a test for the TextBox-Refresh-method (which is significantly slower than DoEvents or Instr, hence a smaller LoopCount)
    T = Timer
      For i = 1 To SmallerLoopCount
         Text1.Text = "SomeContent"
         Text1.Refresh
      Next i
    Debug.Print "avg. CallTime of Text1.Text-setting + TextBox.Refresh: "; Format((Timer - T) * 10 ^ 6 / SmallerLoopCount, "0.0µsec")
    
    'now the Call-Overhead of Text1.Text="SomeText" + DoEvents (also using the smaller LoopCount, but its about factor 12 faster than the above)
    T = Timer
      For i = 1 To SmallerLoopCount
         Text1.Text = "SomeContent"
         DoEvents
      Next i
    Debug.Print "avg. CallTime of Text1.Text-setting + DoEvents: "; Format((Timer - T) * 10 ^ 6 / SmallerLoopCount, "0.0µsec")
    End Sub
    The Results here on my machine came out this way (and the units are BTW micro-seconds, not milliseconds:

    avg. Call-Overhead of DoEvents: 0.5µsec
    avg. Call-Overhead of InStr(): 0.9µsec
    avg. CallTime of Text1.Text-setting + TextBox.Refresh: 109.4µsec
    avg. CallTime of Text1.Text-setting + DoEvents: 7.8µsec

    With the above results in mind (DoEvents even faster performing than Instr), let's see what statements came up in the other thread:

    In the other thread, there was a typical Loop with a very low LoopCount:
    Code:
    For nIndex = 1 To 254
    
       If SendARP(...) = successful Then
    
           Text1.Text = SomeNonExpensiveResultFormatting
           DoEvents 'to allow the TextBox some "breathing-room" for Refreshing - though better would be Text1.Refresh in this case ...
    
       End If
    Next nIndex
    Below is a comment on that (after the original author of the loop stated, that the whole thing needed about a minute or more to complete its 254 rounds):
    Quote Originally Posted by si_the_geek
    Simply removing DoEvents should make it noticeably faster, perhaps by a large amount.
    And that's plain wrong - removing DoEvents in this case, would have sped up the whole thing not even by
    a "pro-mille" - the "loop-total-time" is spend nearly in its entirety in the SendARP-function instead.

    Further down (trying to keep up the myth):
    Quote Originally Posted by si_the_geek
    The time that DoEvents takes to run varies significantly (depending on a wide variety of things about the application, the computer it is running on, other applications/services that are running, and the entire Windows environment at the time), but will clearly be slower than just refreshing a single control.
    Well - to that I simply re-state the two last Timing-results of my small Test-Form:
    avg. CallTime of Text1.Text-setting + TextBox.Refresh: 109.4µsec
    avg. CallTime of Text1.Text-setting + DoEvents: 7.8µsec

    So, the DoEvents-based combination is definitely *not* "slower than just refreshing a single Control"
    (that doesn't mean, that using TextBox.Refresh is the wrong way to go about it - DoEvents *is* evil - but not due to speed-reasons).

    Further speculations include Virus-Scanners as the potential culprit for "really bad DoEvents-performance":
    Quote Originally Posted by si_the_geek
    I don't know all of the causes for it being slower in some cases (one odd case I remember seeing was due to antivirus software, which somehow made it take about 10 seconds per call), but the reasons don't really matter as the solution is far easier than attempting to even work out what the causes are, let alone attempt to work around them somehow.
    Well, just for fun I've started a "Full-Scan" on my Virus-Scanner-App at this occasion - and noticed:
    Not the slightest change in my timing-results (whilst the Virus-Scanner performed its tasks of course).

    So, unless there's a reproducable scenario suggested, which I can try here on my own - I'd say
    my test-results stand as they stand - and the myth is busted.

    Well, Niya posted a Link to another article about this topic:
    http://xnagamedeveloper.wordpress.co...s-back-part-1/

    Starting out quite nicely but then I've stumbled over this deliberate manipulation in the article, which does not
    make any sense ... Why include the StatusBar.Method in its own "reduced refresh-count-block" - but then leave DoEvents
    deliberately outside the "If i Mod 100000 = 0" construct? The sole reason why DoEvents is there at all,
    is to allow for some "breathing-time" for the GUI-Control-Refresh (the StatusBar.hWnd-Paint Messages to get through).

    Code:
        For i = 1 to 10000000 ‘(yes 10 million)
            PerformActions i
            If i Mod 100000 = 0 then
                Me.StatusBar.Value = Me.StatusBar.Value + 1
            End If
            DoEvents()
        Next i
    That, followed by a demonstration of "poor math-skills" made me stop reading further.
    Once it returns it calls the Sleep API function, to end out the time slice give to it by the operating system. The main problem is, the time slice is given is dependant on what needs to be processed. If there is nothing on the queue, there is still a moment of sleeping, milliseconds, sure, but multiply milliseconds by 10 million and it might be significant.
    Ok, let's do just that - we multiply "milliseconds" (plural) by 10Mio.
    2 * 10Mio = 20 Mio-milliseconds = 20Tsd seconds = about 5.5 hours

    But in his examples the Author measured only ~3.6 seconds for 10Mio DoEvents-calls
    (which is 0.36µsec per DoEvents-call and not that far off from my own measured ~0.5µsec calling-overhead).

    What si and Niya (and the Author of the just mentioned article) correctly state,
    is the nature of the DoEvents-call, because it encapsulates the Windows-MessagePump-APIs -
    but these are in place also in the hidden ThunderRT-Main-Loop of any VB-App - so,
    if there's "a flood of messages, which are incoming into the threads msg-queue",
    then those messages have to be handled by the thread, no matter what. The VB-App
    will encounter and handle the same amount of "resulting internal Event-calls" - no matter
    if those messages were encountered inside the DoEvents-Message-Handling and -Pumping-calls,
    or by the "Default-Pump of the VB-App" which is in place otherwise.

    What makes over-usage of DoEvents dangerous, is the "possible re-entrancy issues" - but that has
    nothing to do with performance.

    Olaf
    Last edited by Schmidt; Oct 19th, 2013 at 01:15 PM.

  2. #2
    Super Moderator si_the_geek's Avatar
    Join Date
    Jul 2002
    Location
    Bristol, UK
    Posts
    41,929

    Re: DoEvents and Performance

    You are displaying an impressive amount of bias in attempting to justify your position, and the way you have done it clearly makes most of your points invalid.

    To start with, you did a comparison against .Refresh in an extremely bare application which would blatantly bias the speed in favour of DoEvents - and therefore all of the conclusions you made based on it are completely untrustworthy. The obvious implication for the second time you quoted me was "in a typical application", which is certainly not what you tested (you didn't even go as far as having 2 controls).

    My comment about the virus scanner was blatantly referring to a specific unusual case, rather than virus scanners in general. As such, even commenting on it is rather pathetic, and calls in to question whether you even believe your own position.

    The example in the article Niya linked to was contrived (and strange) presumably in order to keep it simple, but not as badly as yours. As I mentioned in the other thread it is very similar to lots of real cases that are on the forums which are not contrived (which you unsurprisingly chose to ignore here). Just because aspects of that particular article aren't ideal, it does not mean that all of the points it makes are invalid.


    As you are aware I do not have much time to actually post these days due to the time I need to spend on moderator duties, so I will not comment on your other fallacious points... but there are many threads on the forums where it has been proven that using Refresh is noticeably faster than DoEvents in a typical application, so I suggest you search for them (or do proper research into it) rather than clutching at your bias.

  3. #3

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: DoEvents and Performance

    Sorry Si, but as said - unless you come up with links or (for a change) code-snippets you coded on your own -
    I have no reason to believe that anything you said about "DoEvents performing badly" is something other than "believe in a myth".

    Prove your claims as everybody else (Code holds truth, you know) - just repeating yourself does not make wrong claims true.

    You fail to recognize apparently, that the DoEvents-Call (in the normal case, with a near empty Msg-Queue to check)
    performs in the Sub-MicroSecond-range (faster than VBs Instr-function) -
    and the other case to consider is the "flooded message-queue" (which could make DoEvents perform less well) -
    but then I've given you already a hint, why DoEvents performs less well (when you run into other EventHandlers
    of the Application, whilst "being within the DoEvents-calls message-dispatching-functions").

    So that "performing less well" has to be seen in context - it's not the DoEvents-call which "performs less well" -
    it's the time the application would have spent in "all those then indirectly called Eventhandlers" in any case! -
    no matter which Pump was dispatching those messages from the Threads MessageQueue.


    Hopefully I got through this time - the topic (and my argumentation) is not *that* hard to understand IMO.


    Olaf

  4. #4
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: DoEvents and Performance

    Well I have seen cases where removing DoEvents from a loop noticeably increased performance but unfortunately, its not something I come across that often and I can't remember the specifics of the scenarios that produced that result so I can't offer any evidence at this time. That is not to say you're wrong Olaf but Si is also not wrong. I think the problem here is that it's not so much DoEvents itself that is the problem but the messages being processed when its called. That alone adds a tonne of variables to this equation that makes it neigh impossible to predict when DoEvents would perform good and when it wouldn't. Do you have any idea of the amount of messages being pass around right now on your PC, even when you're not doing anything ? Its a lot and they vary widely in their behavior and effects.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  5. #5
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    14,205

    Re: DoEvents and Performance

    Doevents can have different types of impact in different cases.

    For example running a program on a single core pc where other programs are also running or the program you have is using a timer that has some cpu hogging code then a doevents in another sub can drastically alter the speed of the program.

    The main thing is that do events yields execution and allows other events to fire the impact of this is directly related to what those other events are doing, it can be anything from unnoticeable to a drastic difference

  6. #6

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: DoEvents and Performance

    Quote Originally Posted by si_the_geek View Post
    The obvious implication for the second time you quoted me was "in a typical application", which is certainly not what you tested (you didn't even go as far as having 2 controls).
    Ok, that seems like a valid point - so let me expand on that and enhance the example.

    Would you consider 10 open Forms (with in total 1075 active hWnds, with 100 active TextBox-Controls on each Form) as enough?

    I mean, on XP there's a limit of 2000 hWnds per Process (not sure about current Win7-limits in this regard) -
    but I'd think that's OK to simulate a midsized App when this Control-Count is "active" - constantly refreshed
    by a fast running timer (12-15msec) on each of the 10 Forms - the TextBoxes updated randomly within
    each Form - resulting in a Refresh-frequency of about 2*(660-800) = about 1500 Messages (Timer and Paint) per Second in total
    (over all 10 Forms) - so that's what ensures a certain amount of "message-pressure" on the App- (or Doevents-) message-pump at any time.

    Now - here's the ScreenShot:



    As you see - not much change to the unstressed case.

    Here's the updated code (as before - just paste it into an empty VB6-Form, having the default-name Form1 - and be aware, that 10 Forms will pop-up in total).

    Code:
    Option Explicit
    
    Private WithEvents tmrStress As VB.Timer
    
    Private Sub Form_Load()
    Dim i, x, y, F As Form1
    
      Caption = "Click Me!"
      ScaleMode = vbPixels
      Move Left, Top, Screen.Width / 2, Screen.Height / 2
      
      y = 100
      For i = 1 To 100
        With Controls.Add("VB.TextBox", "Text" & i)
            .Move x, y: x = x + .Width + 2
            If x > 0.93 * ScaleWidth Then x = 0: y = y + .Height + 2
            .Visible = True
        End With
      Next i
      Set tmrStress = Controls.Add("VB.Timer", "tmrStress")
          tmrStress.Interval = 10
          tmrStress.Enabled = True
    
      If Forms.Count >= 10 Then Exit Sub
      
      Set F = New Form1
          F.Show
    End Sub
    
    Private Sub Form_Click()
    Dim i As Long, T As Single, Pos As Long, Text1 As TextBox
    Const LoopCount& = 10 ^ 6, SmallerLoopCount& = 1000
    
    Cls
     
    Set Text1 = Me!Text1
     
    'first checking the average Call-Overhead of DoEvents (performing in the Sub micro-second (not milli-second)range)
    T = Timer
      For i = 1 To LoopCount
         DoEvents
      Next i
    Print "avg. Call-Overhead of DoEvents: "; Format((Timer - T) * 10 ^ 6 / LoopCount, "0.0µsec")
    
    'same thing (with the same LoopCount of 1Mio) for the VB-Instr-function in a typical "smaller string check"-setup
    T = Timer
      For i = 1 To LoopCount
         Pos = InStr(1, "SomeStringToCheck", "to", vbTextCompare)
      Next i
    Print "avg. Call-Overhead of InStr(): "; Format((Timer - T) * 10 ^ 6 / LoopCount, "0.0µsec")
    
    
    'a test for the TextBox-Refresh-method (which is significantly slower than DoEvents or Instr, hence a smaller LoopCount)
    T = Timer
      For i = 1 To SmallerLoopCount
         Text1.Text = "SomeContent"
         Text1.Refresh
      Next i
    Print "avg. CallTime of Text1.Text-setting + TextBox.Refresh: "; Format((Timer - T) * 10 ^ 6 / SmallerLoopCount, "0.0µsec")
    
    'now the Call-Overhead of Text1.Text="SomeText" + DoEvents (also using the smaller LoopCount, but its about factor 12 faster than the above)
    T = Timer
      For i = 1 To SmallerLoopCount
         Text1.Text = "SomeContent"
         DoEvents
      Next i
    Print "avg. CallTime of Text1.Text-setting + DoEvents: "; Format((Timer - T) * 10 ^ 6 / SmallerLoopCount, "0.0µsec")
    End Sub
    
    Private Sub tmrStress_Timer()
    Static CC As Currency: CC = CC + 1
    Dim RandomTextBox As TextBox
      Set RandomTextBox = Controls("Text" & (Int(Rnd * (Controls.Count - 1)) + 1))
      RandomTextBox.Text = CC
    End Sub
    Olaf

  7. #7
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    14,205

    Re: DoEvents and Performance

    But what if there is some other code that is waiting for the cpu? something like a timer that runs 10 seconds worth of code when it fires. Doevents may allow that timer to fire and add 10 seconds delay where refresh will not.
    Also as I mentioned a single core PC that has other programs looking for CPU time can cause a much more noticeable difference when using doevents.

    It does have its place as does refresh, the worst part about using doevents IMO is that it can have unexpected side effects, a user clicks a button while your routine is running, switches to a different text box and starts typing, closes the form and so on, in addition to possible incomoming data via rs232 or winsock or a timer firing if you have any of these things in your project, any of which could slow the program or worse.

  8. #8

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: DoEvents and Performance

    Quote Originally Posted by DataMiser View Post
    The main thing is that do events yields execution and allows other events to fire the impact of this is directly related to what those other events are doing, it can be anything from unnoticeable to a drastic difference
    The above is the main-problem I have with all that...

    When you write: "The main thing is that do events yields execution and allows other events to fire" -
    do you think, that those "other Events" are not fired anyways (DoEvents is internally dispatching only already queued messages, thereby releaving the queue - it doesn't create any "additional messages on its own").

    So - as I already stated before - if it is not DoEvents which dispatches those messages from the queue - then the Apps Main-Message-Loop would
    dispatch those messages to the Applications internal EventHandlers - there's not one message more to process by the Application, in case DoEvents
    is dispatching them - the problems with DoEvents arise, due to the "current position on the stack", when these messages are dispatched from
    within DoEvents.

    So, when you conclude with: "... the impact of this is directly related to what those other events are doing, it can be anything from unnoticeable to a drastic difference"
    I can only say: *If* you encountered a drastic difference in performance or speed - then it was not due to calling DoEvents - it is related to other things - maybe
    (at the same place where DoEvents is called repeatedly) there's also a snippet of code, where the developer is responsible for a kind of "Event-flooding" (causing
    Messages to be sent into the Apps Message-Queue).

    E.g. when updating a ProgressBar or some other Control in a high-frequented Loop (without an [If Mod LargerNumber = 0 Then ...] branching),
    followed by DoEvents - then it's not DoEvents which is causing the performance-hog in this case - it's the message-flooding which DoEvents
    has to "pump-out" but without any fault on its own - it was you as the developer who has caused a Message-flooding, by updating a GUI-
    control much too frequently.

    Olaf
    Last edited by Schmidt; Oct 19th, 2013 at 06:44 PM.

  9. #9

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: DoEvents and Performance

    Quote Originally Posted by DataMiser View Post
    But what if there is some other code that is waiting for the cpu? something like a timer that runs 10 seconds worth of code when it fires. Doevents may allow that timer to fire and add 10 seconds delay where refresh will not.
    I already answered that IMO in my previous posting (but both came in at roughly the same time) - so here again:
    If you felt the need, to e.g. let a timer fire "every minute" - and then the timer-job is causing 10sec of uninterrupted stress
    in the application - then that was your decision - your App will block every minute for 10 secs, no matter if the
    timer-event was dispatched from the message-queue by DoEvents or from the Apps-MainMessage-Loop - so don't
    try to blame the DoEvents-function for this 10sec delay - DoEvents has not caused it - the only thing that is different is
    the StackPosition this Event-Code now runs from.

    And as for calling Refresh in favour of DoEvents...
    I thought I made that already entirely clear in my opener-post here, that I'm entirely *with you* in that.
    "DoEvents is evil" - use it as sparsely as possible - ideally use no DoEvents at all in your App - use Control-Refreshs instead
    (and don't overdo the calling-frequency of those Refreshs in tight, high-frequent-loops).

    I have only a problem with the statement, that DoEvents is a performance-hog - and I brought code, which proves, that this is not the case.

    Quote Originally Posted by DataMiser View Post
    Also as I mentioned a single core PC that has other programs looking for CPU time can cause a much more noticeable difference when using doevents.
    I don't see, how - really I don't. If there's only a single core - and the PC is performing e.g. a "Disk-Scan-For-Viruses" (the AntiVir-App then taking up 100% of CPU at this time) -
    then you will see a generally "sluggishly responding system" - and if your App-Code at this point of time performs heavy Disk-activities too, then your App is even more affected by
    the parallel access of the single disk-resource.
    Last edited by Schmidt; Oct 19th, 2013 at 06:45 PM.

  10. #10
    Lively Member
    Join Date
    Oct 2013
    Posts
    124

    Re: DoEvents and Performance

    Many years ago there was a website, named XtremeVB if I remember correctly. They spent a lot of time profiling different ways of doing things in the interest of speed.

    It seems that they recommended something besides DoEvents. Unfortunately, it never mattered to me. I've only written one program that took more than 24 hours to run. I hardly ever use DoEvents even. My programs do unusual things, and I feel no need to speed them up, even though I did just write a Binary File Copy application. (Every Microsoft application connected to the Windows Control Panel is a piece of crap and I am replacing it all as fast as I can.)

  11. #11

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: DoEvents and Performance

    Quote Originally Posted by Honduras 2811 View Post
    Many years ago there was a website, named XtremeVB if I remember correctly. They spent a lot of time profiling different ways of doing things in the interest of speed.

    It seems that they recommended something besides DoEvents.
    I also recommend something beside DoEvents - the Refresh-Method of the Controls in question.
    Or - for that matter - Timers, to trigger "seemingly parallel actions on a single thread" ... or multiple threads, in case you want a true decoupling ...

    Well, and as for XtremeVB, recommendations etc...
    Without a concrete Code-Snippet (what was recommended and why) - or a concrete Link, all that talk remains "nebulous" and is not much help ...

    So, until somebody comes up with something "reproducible and entirely surprising", I'd stick (run and test) the very concrete Demo-Code I've provided in this thread -
    what more do you need, to form your own opinion?

    Olaf

  12. #12
    Super Moderator si_the_geek's Avatar
    Join Date
    Jul 2002
    Location
    Bristol, UK
    Posts
    41,929

    Re: DoEvents and Performance

    Quote Originally Posted by Schmidt View Post
    Sorry Si, but as said - unless you come up with links or (for a change) code-snippets you coded on your own -
    I have no reason to believe that anything you said about "DoEvents performing badly" is something other than "believe in a myth".
    Wow... trying to claim victory by default really strengthens your position!

    I spend an hour or two every day on moderating duties (over 30 minutes so far today, and its not even a third of the way thru the day), and have other things to do away from the forums, so I'm not going to waste time re-proving things that have been proven before (including by me and many others on this site).

    If you can't bother to discuss things in an intelligent manner (such as being polite, and finding existing counter evidence when prompted), then you are just harassing so that you can have an argument.
    You fail to recognize apparently, that the DoEvents-Call (in the normal case, with a near empty Msg-Queue to check)
    performs in the Sub-MicroSecond-range (faster than VBs Instr-function) ...
    Stop pretending that I am ignorant just because I don't agree with your position. A nearly empty message queue happens, but is certainly not the case in every piece of code where DoEvents is used.

    Hopefully I got through this time - the topic (and my argumentation) is not *that* hard to understand IMO.
    It isn't hard to understand, but your points are biased and flawed, and therefore not believable.

    The fact you haven't even bothered to find existing counter evidence after being prompted increases the reasons to not accept your view as "the all encompassing truth".

    You are the one who wants to spend time on this, don't attempt to claim your point of view is always correct just because others aren't willing to get as involved in it as you.
    Quote Originally Posted by Schmidt View Post
    Ok, that seems like a valid point - so let me expand on that and enhance the example.
    That is an improvement, but is still clearly biased. Uses outside of your attempts to support your position would not be using such simple code.

    Quote Originally Posted by Schmidt View Post
    When you write: "The main thing is that do events yields execution and allows other events to fire" -
    do you think, that those "other Events" are not fired anyways (DoEvents is internally dispatching only already queued messages, thereby releaving the queue - it doesn't create any "additional messages on its own").
    Nobody has made any kind of claim implying that it directly creates messages.

    What it does do (among other things) is create situations where messages are processed earlier than they would have been, and therefore more messages are created (eg: due to an external sender using SendMessage rather than PostMessage, or Windows sending another paint message, etc).

    From VB6 help:
    DoEvents passes control to the operating system. Control is returned after the operating system has finished processing the events in its queue
    From http://support.microsoft.com/kb/158175 :
    DoEvents is a Visual Basic function that yields execution so the operating system can process other events. This function cleans out the message loop and executes any other pending business in the Visual Basic runtime. Upon completing the pending business execution, the function calls the Sleep function with zero (0) as the argument so that the remaining time slice can be used to check the queue.
    Due to yielding to external processes, it clearly adds a delay, and to some degree allows the generation of extra messages.

    How much effect those things have will clearly vary wildly based on circumstances.

    So - as I already stated before - if it is not DoEvents which dispatches those messages from the queue - then the Apps Main-Message-Loop would
    Generally the main message loop only acts after the code has stopped, which seems to eliminate lots of duplication (eg: I'm fairly sure duplicate paint messages aren't processed) and therefore saves time.

    Quote Originally Posted by Schmidt View Post
    I have only a problem with the statement, that DoEvents is a performance-hog - and I brought code, which proves, that this is not the case.
    That is not true... all you have proven is that isn't a hog under a particular kind of biased circumstances.

  13. #13
    New Member
    Join Date
    Sep 2009
    Posts
    2

    Re: DoEvents and Performance

    Olaf, thank you very much for writing all the code to demonstrate that DoEvents is not a drag on performance. It was enlightening and will be very valuable in speeding up my programs.

    Regards,

    John

  14. #14

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: DoEvents and Performance

    Quote Originally Posted by si_the_geek View Post
    The fact you haven't even bothered to find existing counter evidence after being prompted...
    Sorry - I was already aware, that there's no "counter-evidence" available which proves that "DoEvents slows down your App" -
    because my concrete Code already proves otherwise (and aside from that, I've participated in or read dozens - (perhaps even hundreds) -
    of VB-discussion-threads over the last two decades, where there was nowhere any evidence given, that "DoEvents is affecting App-Performance badly".

    So, this "mythical proof" seems to be deeply hidden somewhere in the VBForums-archives - and I did a search now, but all I find is stuff like:

    http://www.vbforums.com/showthread.p...y-better-ideas
    No proof found there.

    http://www.vbforums.com/showthread.p...s-quot-to-wait
    No proof found there.

    http://www.vbforums.com/showthread.p...about-Doevents
    No proof found there (only speculations).

    http://www.vbforums.com/showthread.p...about-DoEvents
    No proof found there.

    http://www.vbforums.com/showthread.p...-DoEvents-When
    No proof there either.

    http://www.vbforums.com/showthread.p...ot-crashing-VB
    No proof - as in each of the other threads - I find only re-stating of the myth without anybody giving any evidence (preferably per code).

    http://www.vbforums.com/showthread.p...esponding-quot

    Also no proof found... so I'm giving up on the topic ... also because it is not really my obligation in a well-led technical discussion,
    to find counter-proof to things I postulated myself and *gave* already evidence for (per test-code).

    In this latest of the above links, you participated yourself - but your statement: "as it will slow down your code, perhaps drastically" is still only a claim.
    (At this occasion - what I've found code-wise is only your wrong snippet where you encouraged the OP to use DoEvents behind a Modulo-Op...
    basically right, but then you gave the wrong If-expression - you might want to edit this part "for the sake of correctness in the archives").

    So, I really read all the contributions about DoEvents in the above linked threads - I wasn't "just posting links" -
    but you cannot really expect a fellow developer, who posted an opinion different from yours - to do your work for you
    and dig out (seemingly non-existent) evidence for the counter-position in a technical debate... this obligation does
    *especially* not exist, when "evidence which supports a thesis" was already given (as in my code-examples).

    So far, my observation: It is only a myth that "DoEvents reduces App-performance", still stands.

    If a certain thing is "blatantly obvious" (and you act, as if you're *deeply* convinced, that DoEvents slows down even small loops from 1 to 254) -
    then it should be totally easy, to either write some code-snippet-proof for it - or to dig out one of the countless links where such code (or proof) was already given by others.

    Maybe somebody else (in case you have no time for proving your own belief) is willing to help out with a link or a code-snippet.
    (DataMiser, DigiRev mayhap - or whoever else was making statements in the above linked threads, that "DoEvents slows down things considerably")

    Olaf

  15. #15

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: DoEvents and Performance

    Quote Originally Posted by JPCoffey View Post
    Olaf, thank you very much for writing all the code to demonstrate that DoEvents is not a drag on performance. It was enlightening and will be very valuable in speeding up my programs.
    Ah, thanks for recognizing the efforts I've put into that article - now I can only hope that your:

    "(it) ... will be very valuable in speeding up my programs..."

    is not resulting in attempts, to put "a whole lot more DoEvents in, for speedup-purposes"

    Not being a drag doesn't mean that DoEvents should be over-used - it can unexpectedly relay into
    (at this time unwanted) Event-Handlers in your Application and mess-up your stack, when more than one
    single "DoEvents-Loop" is active at a given time in your Application.

    But I've mentioned that already - as well as a few alternatives to DoEvents, as Timers and Threads.

    Olaf

  16. #16
    Super Moderator si_the_geek's Avatar
    Join Date
    Jul 2002
    Location
    Bristol, UK
    Posts
    41,929

    Re: DoEvents and Performance

    Quote Originally Posted by Schmidt View Post
    Sorry - I was already aware, that there's no "counter-evidence" available which proves that "DoEvents slows down your App" -
    because my concrete Code already proves otherwise
    For the kind of unrealistic example you gave, yes. It is ridiculous to claim that it proves your case for all situations.

    I have a commercial application here which contains evidence (for an animation sequence, DoEvents is about 40% slower than .Refresh, and using neither is about twice as fast), but clearly I am not going to share that just to refute your claims.
    it is not really my obligation in a well-led technical discussion,
    to find counter-proof to things I postulated myself and *gave* already evidence for (per test-code).
    It basically is your obligation, because you are trying to disprove something (which means to be taken seriously, you need to 'correct' previous real evidence, rather than just creating an example that is clearly heavily contrived in your favour).

    It is unfortunate that you didn't manage to find any previous evidence, but you seem to be the one who really cares about this, so don't expect others to give up their time to find it.
    In this latest of the above links, you participated yourself - but your statement: "as it will slow down your code, perhaps drastically" is still only a claim.
    As the OP didn't even show their code (let alone share timings, as some have done), yes.. but given what was mentioned about the code, there is a definite possibility.

    What is clear is that it will slow down the code (as even in the best case, it takes some time to run), what is debatable is by how much (depending on the code etc it could be anywhere from a fraction of a millisecond to several hours).
    (At this occasion - what I've found code-wise is only your wrong snippet where you encouraged the OP to use DoEvents behind a Modulo-Op...
    basically right, but then you gave the wrong If-expression - you might want to edit this part "for the sake of correctness in the archives").
    Done.

    So far, my observation: It is only a myth that "DoEvents reduces App-performance", still stands.
    You should be careful how you word things... that implies using Mod or an equivalent is a bad idea, and that DoEvents doesn't take any time at all in any situation (both of which contradict things you have already posted).

    Maybe somebody else (in case you have no time for proving your own belief) is willing to help out with a link or a code-snippet.
    (DataMiser, DigiRev mayhap - or whoever else was making statements in the above linked threads, that "DoEvents slows down things considerably")
    Maybe they will, but due to some of your previous behaviour, it is unlikely that anyone will bother.

    Given the amount of my time you have intentionally wasted before, I certainly wont be bothering.
    Last edited by si_the_geek; Oct 25th, 2013 at 06:45 AM. Reason: removed some parts of the end section which went too far

  17. #17
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: DoEvents and Performance

    Oh God Olaf, give it rest already. Why do you keep provoking people ? I think every point that could have been made has already been made about this topic on DoEvents. No reason to drag this into the gutter now. There's really no right or wrong here.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  18. #18
    PowerPoster
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    2,412

    Re: DoEvents and Performance

    I don't understand why everyone is getting so angry? It's an interesting topic to explore long-held "truths" and see if they are withstand scrutiny, or if they are just cargo cult thinking. I think there is a fair amount of VB "knowledge" that is basically cruft left over from past versions of the language and older versions of Windows that maybe doesn't hold true anymore.

    Anyway, maybe Olaf is right, or maybe he's wrong, but he's interested in exploring the topic and demonstrating his point with concrete examples, so more power to him. If you don't care about the topic, or have made up your mind about it without caring about new evidence, or if you don't trust, or otherwise don't believe Olaf, then fine - there's no imperative to contribute to the discussion.

    In any case, DoEvents is kind of a funny thing to get wound up over anyway, since there's almost always a better/safer option. But IMHO, if we're going to discourage people from using it, it makes sense to provide real reasons why it shouldn't be used, and not just say "it will kill performance", when that is not necessarily (or even commonly) so, if indeed that is the case.

  19. #19
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: DoEvents and Performance

    Its not really that Olaf is wrong but the nature of DoEvents itself makes it hard to form any worthwhile concrete stance on its performance. Olaf made his point well. I can't argue with its findings however, I've also observed what Si is saying to be true. I've seen DoEvents degrade performance noticeably. In 8 out of 10 cases DoEvents won't degrade performance so its obviously more difficult to contrive an example that shows the 2 out of 10 cases. In the cases I encountered it, I was never even sure why, I just fixed it and moved on without a second thought. If I had known then I'd be having a discussion about it on a forum years later, I would have paid more attention to the details of the scenario and commit it to memory but I didn't so I cannot provide solid proof.

    Its doubtful that I would encounter such a case again since I don't use VB6 anymore and VB.Net's easy multi-threading eliminates the need for DoEvents altogether. I may never write another program with DoEvents in it again so I guess proof from me would be lost to eternity. Maybe someone else can pick up on that. As interesting as this discussion is, its not enough so for me to go poking around in VB6 again to try and reproduce this rare occurrence.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  20. #20
    PowerPoster
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    2,412

    Re: DoEvents and Performance

    Fair enough Niya - and to be honest, I'm not particularly interested in DoEvents myself, except academically, since I never use it. But I'm always interested in expanding my knowledge, and I admit to having a fondness for seeing long-held beliefs and common wisdom challenged by evidence.

  21. #21
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    400

    Re: DoEvents and Performance

    I was following the thread with interest when, suddenly, I realized that the last Olaf's post was deleted (even after being insulted he said nothing that could lead to that). Are super-moderators moderated?

  22. #22
    Super Moderator si_the_geek's Avatar
    Join Date
    Jul 2002
    Location
    Bristol, UK
    Posts
    41,929

    Re: DoEvents and Performance

    Quote Originally Posted by jpbro
    Anyway, maybe Olaf is right, or maybe he's wrong, but he's interested in exploring the topic and demonstrating his point with concrete examples, so more power to him. If you don't care about the topic, or have made up your mind about it without caring about new evidence, or if you don't trust, or otherwise don't believe Olaf, then fine - there's no imperative to contribute to the discussion.
    As I mentioned somewhere above he is right, but only for a limited range of cases (a loop with no meaningful code, in an almost bare application). It doesn't apply to every case, but unfortunately I can't share the proof I have.

    Exploring something like this can be good (I've done it many times myself, and joined others when they've done it), but it should be kept to a sensible discussion with willing participants, rather than using various troll tactics to drag them in and stop them from leaving.

    Hopefully Olaf will have got that completely got that out of his system before he comes back.

    Quote Originally Posted by Carlos Rocha View Post
    I was following the thread with interest when, suddenly, I realized that the last Olaf's post was deleted (even after being insulted
    While what I said at the end of my previous post wasn't nice, there is public evidence that supports it.

    I'm not happy about what I posted, but I am too tired to work out what to do about it at the moment... hopefully I will get a chance to sort it out tomorrow.
    he said nothing that could lead to that).
    Actually he did, but it is site policy to not discuss ban reasons.

    There are a variety of things Olaf has done in his time here that are unacceptable which are public knowledge (such as intentionally breaking rules), which many members have tried to get him to stop doing. There are also some things which are only known between him and moderators/admins.

    What Olaf did this time was enough for a temporary ban (his history affects the duration).
    Are super-moderators moderated?
    We are indeed, and Olaf is well aware of that.

    If Olaf genuinely believes he doesn't deserve it, he will presumably be discussing it with the admins, who may increase or decrease the length of the ban.

  23. #23
    Hyperactive Member
    Join Date
    Jul 2013
    Posts
    400

    Re: DoEvents and Performance

    Si, I can only talk about what I saw, and even after reviewing the full thread I didn't find anything offensive from Olaf. Sarcasm maybe, but in a level that can't be seen as offensive, imho.
    Anyway, the thread is still alive, and you are the only one (from the original contenders) who can talk about it. Unfair, to say the least.
    Enough said from me.

  24. #24
    PowerPoster jcis's Avatar
    Join Date
    Jan 2003
    Location
    Argentina
    Posts
    4,430

    Re: DoEvents and Performance

    Posting things not related to technical stuff in this specific subforum is not something i like to do but i need to make an exception here.

    Olaf is a VB Guru, anybody with some knowledge in VB would notice that, i noticed just after the first post I've read from him here at VBF, and I can tell i don't think i've ever seen somebody with his level ever before, maybe Joacim answers here at VBClassic (so many years ago) could be the only thing i can imagine can be compared to this.

    Olaf is also very passionate, he obviously loves all this (technical) stuff, he can plant a challenge anywhere and anytime when there si a topic that deserves it, what's the problem with it? I like it, who won't? If somedoby is flooding the Forums with knowledge, the sort of knowledge you don't see quite often these days, what will you do? Would you BAN the guy? Even worse: Would you ban the guy without explaining the reasons? What do you think other members will think?

    @SI: I respect you, you helped me a lot back in 2003 when i joined the forums and I respect all you've been doing for this forums but in my opinion you shouldn't do this, i don't think he's just "challenging" other members, i think he's "challenging" ideas, misconceptions, etc.. and he can backup all he says with 20 years experience. I try to understand your comments but didn't find anything offensive from Olaf, now he's banned and i have a question: When Olaf created a thread in the Codebank some time ago there was a discussion with Niya, in that thread Niya broke the Forums Policies multiple times with multiple insults in multiple posts, Koolsid edited all that threads if i'm not mistaken.. Why nobody banned Niya?

    With so many mediocre and uninformative threads this poor subforum has these days, let's appreciate value when it comes, let's not kick it out... please.
    Last edited by jcis; Oct 25th, 2013 at 10:00 PM. Reason: spelling

  25. #25
    Super Moderator si_the_geek's Avatar
    Join Date
    Jul 2002
    Location
    Bristol, UK
    Posts
    41,929

    Re: DoEvents and Performance

    Olaf does have very good VB knowledge, but he also treats others in a way that is not allowed on this site (part of which I hinted at in my previous post), despite multiple previous warnings - and several public attempts from multiple members (about 10?) to persuade him to stop.

    As I said in my previous post, I hope when he returns the bad elements are gone - so that people can benefit from the good things he has to offer.

    Challenging ideas is a good thing, but it needs to be done in a more polite way than he has done here (particularly the deleted post).


    As for explaining reasons for a ban (or the private actions against both members in that CodeBank thread), that is out of my hands - it is site policy (dictated by Brad) to not discuss that kind of thing.
    Quote Originally Posted by Carlos Rocha View Post
    Anyway, the thread is still alive, and you are the only one (from the original contenders) who can talk about it.
    That is only temporary, because Olaf intentionally crossed a line despite previous warnings.

  26. #26
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: DoEvents and Performance

    Quote Originally Posted by jcis View Post
    Posting things not related to technical stuff in this specific subforum is not something i like to do but i need to make an exception here.

    Olaf is a VB Guru, anybody with some knowledge in VB would notice that, i noticed just after the first post I've read from him here at VBF, and I can tell i don't think i've ever seen somebody with his level ever before, maybe Joacim answers here at VBClassic (so many years ago) could be the only thing i can imagine can be compared to this.

    Olaf is also very passionate, he obviously loves all this (technical) stuff, he can plant a challenge anywhere and anytime when there si a topic that deserves it, what's the problem with it? I like it, who won't? If somedoby is flooding the Forums with knowledge, the sort of knowledge you don't see quite often these days, what will you do? Would you BAN the guy? Even worse: Would you ban the guy without explaining the reasons? What do you think other members will think?

    @SI: I respect you, you helped me a lot back in 2003 when i joined the forums and I respect all you've been doing for this forums but in my opinion you shouldn't do this, i don't think he's just "challenging" other members, i think he's "challenging" ideas, misconceptions, etc.. and he can backup all he says with 20 years experience. I try to understand your comments but didn't find anything offensive from Olaf, now he's banned and i have a question: When Olaf created a thread in the Codebank some time ago there was a discussion with Niya, in that thread Niya broke the Forums Policies multiple times with multiple insults in multiple posts, Koolsid edited all that threads if i'm not mistaken.. Why nobody banned Niya?

    With so many mediocre and uninformative threads this pour subforum has these days, let's appreciate value when it comes, let's not kick it out... please.
    I would not deny that Olaf is extremely knowledgeable. I've said that myself more than once. However, he takes this to mean that he can talk to others in whatever manner he chooses. That whole fiasco with him and me in that other thread was started by him. I was nothing but cordial in the beginning with him but he used a very sarcastic, condescending and slightly abusive tone toward me which I eventually took issue with and responded with venom of my own. Koolsid warned me to stop or face a ban and I complied, the reason I wasn't banned. Olaf however, continually provokes people with his "high and mighty" attitude. He was destined to get banned eventually. I knew this from the first time we every got into a heated discussion that he would run afoul of the mods here one day.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  27. #27
    PowerPoster
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    2,412

    Re: DoEvents and Performance

    @si_the_geek

    I really feel that there is just a big misunderstanding here, and things have snowballed out of control a bit, so let's consider the possibilities:

    Let's assume the best:

    Based on Olaf's contributions to the VB6 community vis-a-vis vbRichClient5, and his compilation and integration of SqlLite and Cairo into VB6, and his ongoing support of those libraries, or

    Let's assume the worst:

    Olaf has been slowly releasing powerful extensions to VB6 to lull us into complacency over the past few years, and then not only try to insult us, but actually "troll" us, just because...?

    Or let's consider the middle ground:
    I know that Olaf is new to the vbforums community, and that he's rocked the boat a little bit, but I think that there is some language barrier here (both german>english, and just general written language vs. typed language), and just some general misunderstandings.

    I know emphatically that Olaf is *not* a troll, he is the real deal.

    What I hope is that we can all talk openly, and basically reset the conversation, because I think it has gotten emotionally out of control, but not irreconcilably so. Please let's get back to putting our efforts into discussing the programming language that we love.
    Last edited by jpbro; Oct 25th, 2013 at 10:55 PM.

  28. #28
    PowerPoster
    Join Date
    Jul 2006
    Location
    Maldon, Essex. UK
    Posts
    6,334

    Re: DoEvents and Performance

    I was following this and the other thread with interest. However, some of the phrases Olaf used did make the hairs on the back of my neck rise.

    It's one thing making disparaging remarks to someone when face to face - you have the advantage of Body Language and can tell whether it's in jest or seriousness - it's completely different thing when you publish it. If I have a face to face discussion with someone and say "If you think that, then you're a bigger idiot than I thought", with a big smile on my face, it's unlikely to cause offence. However, if I posted such a comment here, I'd expect a PM from a Moderator.

    Perhaps Olaf should have used a few smilies in his posts to reduce the risk of causing offence and the consequences thereof. After being asked to 'tone it down' and having not done so, Olaf left the Moderators with little choice.

    I hope it's not a long ban and Olaf is back soon.

    (and of course, we all must let the Moderators moderate)
    Last edited by Doogle; Oct 26th, 2013 at 02:48 AM.

  29. #29
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Re: DoEvents and Performance

    I sure hope you did that ban short and sweet because VF doesn't want to loose such a resource as Olaf. Yes, he has a somewhat "edgy" language and having German roots myself, and being a vbRichClient (it originally was called dhRichClient) user since many years, it didn't surprise me that he eventually stepped on some toes here, but I can only vote in with posters above that he's the real deal and not a troll. I respect the Moderators though and the valuable work they do, and no one is perfect. But after have been "lost" for some time I was extremely happy that he had found it's way here, so I do hope he will take it in a good way and come back. Personally, I think he should spend more time on writing docs and sample code for his excellent libraries, so they could become more "accessible" in an earlier stage by VB6 users. So hear my voice Olaf ;-)

    Now I would like to bring this back on topic by asking "So when is the right time to use DoEvents in code?"
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

  30. #30
    PowerPoster
    Join Date
    Jul 2006
    Location
    Maldon, Essex. UK
    Posts
    6,334

    Re: DoEvents and Performance

    I think the Documentation makes it quite clear
    DoEvents is most useful for simple things like allowing a user to cancel a process after it has started, for example a search for a file. For long-running processes, yielding the processor is better accomplished by using a Timer or delegating the task to an ActiveX EXE component.. In the latter case, the task can continue completely independent of your application, and the operating system takes case of multitasking and time slicing.

  31. #31
    Super Moderator si_the_geek's Avatar
    Join Date
    Jul 2002
    Location
    Bristol, UK
    Posts
    41,929

    Re: DoEvents and Performance

    Quote Originally Posted by jpbro View Post
    @si_the_geek

    I really feel that there is just a big misunderstanding here, and things have snowballed out of control a bit, so let's consider the possibilities: ...
    There is a misunderstanding, but I'm afraid it is not on the part of the moderating team or Olaf.


    Olaf has intentionally repeatedly broken the rules of this site, and has admitted that publicly more than once. While it is less clear in this thread than in the other publicly visible cases (particularly since the post above was deleted), he did intentionally break the rules here, despite multiple explicit warnings (public and private) that it was not acceptable.

    Olaf has made it very clear that it is not a language barrier or a misunderstanding, he just thinks it is amusing to act in a way that he knows is not acceptable on this site. No matter how much you respect his coding skills, it is very strange to say he should be allowed to repeatedly violate the rules of this site without any kind of punishment.

    The good things he has done mean that he has been given more tolerance in the past than most would have got (at least 3 of his previous intentional rule violations would have meant a ban for most people), but the moderating team are not going to let him keep on violating the rules and wasting large amounts of our voluntary time just because he finds it amusing.

    Being a troll (along with the other things he has decided to do) is totally unrelated to coding skills etc, it is about how you conduct yourself. One of the several examples of troll behaviour he displayed in this thread was breaking the rules in a more subtle way than in previous cases, as it allows some people to think he didn't do anything wrong, and instead blame me for enforcing the rules that he was well aware he was violating - and thus need to waste even more of my time (which Olaf knows is in very short supply these days) on posts like this one.

    Olaf does not get to decide what the rules of this site are, and neither do I, and neither do the members who have supported his actions (especially as there are more than twice as many who have stated opposing views in previous threads).


    For anyone who wants him to stay, persuade him to respect the rules of this site, and do it quickly - the moderating staff (and several members) have already tried and failed, and nobody is worth the amount of unnecessary effort he has intentionally caused us (in the entire history of this site only a few have been worse, and most of them did it over several years).

    Quote Originally Posted by jpbro View Post
    Please let's get back to putting our efforts into discussing the programming language that we love.
    Quote Originally Posted by 7edm View Post
    Now I would like to bring this back on topic by asking "So when is the right time to use DoEvents in code?"
    Thank you.

  32. #32
    Addicted Member
    Join Date
    Jun 2010
    Posts
    182

    Re: DoEvents and Performance

    I didn't intended to comment further on this thread (which if I was moderator would have considered to lock at this point as there is nothing more to prove) and to take a stand pro/against the ban I would have to at least eye through the 300+ posts Olaf has done since arriving in June. I don't doubt the mods feel justified in the decision and may as well be right, but in all fairness, in this thread, I feel I have to say that the way si_the_geek, as an moderator, came out in response to OP
    Quote Originally Posted by si_the_geek View Post
    You are displaying an impressive amount of bias in attempting to justify your position, and the way you have done it clearly makes most of your points invalid.
    was unnecessarily provocative, especially when ending it with

    Quote Originally Posted by si_the_geek View Post
    As you are aware I do not have much time to actually post these days due to the time I need to spend on moderator duties, so I will not comment on your other fallacious points... but there are many threads on the forums where it has been proven that using Refresh is noticeably faster than DoEvents in a typical application, so I suggest you search for them (or do proper research into it) rather than clutching at your bias.
    And to be honest, if I had been a Moderator I sure had given you a warning <no pun intended> for that provocative language, especially due to the amount of unnecessarily emphasising adjectives as "blatantly (bias), extremely, completely untrustworthy, rather pathetic" used in between. I can understand if you were effected by earlier encounters with Olaf, but I can also understand him getting triggered by it. Not defending him, or accusing you, just pointing out the fact that it usually takes 2 to dance. Olaf certainly has an extreme personality, and maybe (I don't know) poor sense of borders, especially when he fire away, and probably lack much of the sense for tact and finesse when entering in to a new community, but he does so with an enormous generosity and yes and maybe unfortunately, it also includes his way and thrill for argumentation. But to get back to the point, he's a very technically focused person and I cannot see anything else in his initial post that he wanted to make a case for that DoEvents technically wasn't the performance hog that he felt others in a miss-wording way pictured it and I think he pretty much "proved" that, but it didn't exactly fall in good soil but provoked some history.

    Personally, I have been away for some time so didn't first notice his arrival and hence his posting from the beginning, but when a vbRichClient related search led me here and to a post from him, I must say it made me happy as although I don't know him personally I know he has an enormous wealth of (not only) VB6 knowledge and doesn't hesitate to share it. Sure, it doesn't give him a free card to break the rules that apply here, I certainly agree about that, but also if this is not well received by others (who may even feel threatened/challenged by his knowledge) it doesn't give them a free card to have him pay for it either. Personally, and psychologically, I think he has put so much time and effort into vbRichClient and VB6 at all, without getting back a proper recognition for his contribution, possibly due to bad communication skills, although he may not like to admit to that. But his work is actually so ground breaking and important for the VB6 community, with a perspective to give it an after life when the day comes (and it will) when VB6 apps no longer will run on the latest Windows OS and the whole collected code bank will render worthless. Like it or not, but when it comes down to this he actually is "King" and maybe we should help/teach him to "rule" in a proper way, rather than to refuse or try to kick him down? Actually, I wouldn't mind to see a dedicated sub forum for vbRichClient, partly as a tribute to Olaf's community contribution (possibly excluding some of his most argumentative posts ;-), but mostly because it's an outstanding tool set, without comparison not only for the price, and because it would be a constructive solution to a, let's call it, dynamic problem - giving it a home (technically speaking). It would imho increasing the value of this site. However, if so and if there is a need for discussion/argumentation it should probably be held in a dedicated thread, and not here. It felt right to give this comment here though, but with that I would also like to turn back to it's beginning of it with a suggestion that it will be locked as there really isn't anything more to discuss here.

    /Joakim Schramm
    M$ vs. VB6 = The biggest betrayal and strategic mistake of the century!?

  33. #33
    New Member
    Join Date
    May 2013
    Posts
    2

    Re: DoEvents and Performance

    I subscribe nearly all words from 7edm/Joakim: he had said with better words what I was thinking myself.

  34. #34
    Super Moderator si_the_geek's Avatar
    Join Date
    Jul 2002
    Location
    Bristol, UK
    Posts
    41,929

    Re: DoEvents and Performance

    Quote Originally Posted by 7edm View Post
    And to be honest, if I had been a Moderator I sure had given you a warning <no pun intended> for that provocative language, ...
    My comments weren't particularly nice, but bear in mind that there are signs that this thread (like multiple previous threads) was created to provoke me, rather than to have a sensible discussion as he would like people to think. There is provocation in several parts of the first post, and the link to this thread back in the original thread. The provocation in this case was much subtler than his previous ones, but the history of maliciousness towards me increases the effects.

    Due to his previous warnings, it would have been perfectly valid to ban him for his first post here and the post linking to it, but instead I tried to turn it to a sensible and reasoned discussion. I didn't respond in the nicest way, but given limited time (which he already knew) and the provocation, it could easily have been far worse - and is not as bad as he has managed to provoke some other members in to.

    My first line is justified, because I am well aware (as I hope most others are) that he has the VB skills to know that due to what DoEvents does the original example is clearly not a suitable test, and the results (of that, and the other example) do not apply to all projects as he has claimed. As he has done (and admitted to) before, he put in some valid points to make it seem like he was being valid overall.... which is annoying as he is spreading misinformation in addition to some truth, and some people have believed the misinformation.

    While my posts have not been perfect (to some degree tainted by his past behaviour, including several malicious lies about me), they have not been rule violations.

    I have been a moderator here for about 10 years, and been involved in many similar cases, and had many complaints against me - with only one being determined to be justified. That kind of history would not happen if I allowed personal factors to alter the way I perform my moderator duties.

    but with that I would also like to turn back to it's beginning of it with a suggestion that it will be locked as there really isn't anything more to discuss here.
    Agreed, thread closed.


    As somebody who would like to see him remain at this site sharing his knowledge etc, I feel it is a good idea to re-iterate this point:
    Quote Originally Posted by si_the_geek View Post
    For anyone who wants him to stay, persuade him to respect the rules of this site, and do it quickly - the moderating staff (and several members) have already tried and failed, and nobody is worth the amount of unnecessary effort he has intentionally caused us (in the entire history of this site only a few have been worse, and most of them did it over several years).

  35. #35
    ex-Administrator brad jones's Avatar
    Join Date
    Nov 2002
    Location
    Indianapolis
    Posts
    6,608

    Re: DoEvents and Performance

    Admin addition:

    I took a look at this thread. While it is closed, I thought I'd add an observation / comment:

    The initial post read to me like it was intended to provoke Si. It seemed written to for that purpose as much as to present a coding observation.Others have agreed with this as well.The additional posts within the thread seemed to confirm that feeling as well. Whether that is the case or not, is not relevant in the end. I would have liked to have seen Si leave the thread alone, however, it was pointed at him.

    I'm absolutely all for discussions on coding and coding efficiencies. I believe, however, it is critical to remember that different situations are gong to result in different results -- as was stated.

    Let's keep the discussions on coding going, but let's make sure we are doing it for the right reasons. Let's allow people to disagree. Let's focus on the code since that is how we learn and get better at coding.

    Thanks,

    Let's move on to some new code.....
    Have you given out your reputation points today? Select the Rate This Post link to give points for good posts!
    -------------------------------------------------------------
    Brad! Jones
    Lots of Software, LLC
    (I wrote: C Programming in One Hour a Day) (Dad Jokes Book) (Follow me on Twitter)

    --------------------------------------------------------------

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width