Acceleration DC_GetProgress

[Eugene Lutsenko]

Recently I noticed that one process in the system that I am developing, very slow. For a long time could not understand what was happening and tried to optimize it, but to no avail. It is not understood that it inhibits the function DC_GetProgress (), which I commonly use, because it is very convenient. Once substantially reduced the number of calls to this function once the system is very much faster (about 30 times).

Roger!

Are there any possibilities to somehow speed up the work of this function, or to make it to work independently of the other processes, ie, It did not stop the processing of commands is not satisfied?

[Victorio]

Hi, Eugene,

I had also this problem, after disabling Cancel button (with appevent controlling) process with progress visualisation run good.
Now I have disable Cancel, but I must see it, because long processes can stop now only with CTRL+C...

[Auge_Ohr]

Once substantially reduced the number of calls to this function once the system is very much faster (about 30 times).

hm ... did you use 4th Parameter "nEvery" ?

[Victorio]

Hi,

Maybe this is another problem but I used this :

STATIC FUNCTION _Progressuni2(oProgress,lOk,poradie,maxpocet,krok)
*LOCAL nMaxCount:=RecCount()

DC_GetProgress(oProgress,poradie,maxpocet,krok)
* krok is step
* maxpocet is max number, records of file...

* if enabled, process run slow, if disabled, process run good, but cannot break with Cancel button
*DC_AppEvent(@lOk,0,.01)

RETURN lOk

In another thread Roger write me source of function DC_AppEvent, because I do not know what parameters this fnc have, I tryed several number, 0.001,0.1,1,10,... but no effect.

Note : before I used DC_waiton(), but DC_GetProgress is better, I think DC_waiton slowing process more.

[Eugene Lutsenko]

Waiting for the process interrupt events (usually click on Cancel) and its processing, ie, verification that Cancel button has been pressed, the process is also very slow. Also, do not always caught by the event itself, ie, pressing Cancel. But I'm not asking about that and specifically about function DC_GetProgress().

4th parameter "nEvery" I did not use, and it gives?

[Auge_Ohr]

4th parameter "nEvery" I did not use, and it gives?

look into x:\exp20\Source\Dclipx\_DCGETBX.PRG

Code: Select all

FUNCTION DC_GetProgress( oProgress, nCurrCount, nMaxCount, nEvery, lBar )

   DEFAULT nCurrCount := 0
   DEFAULT nMaxCount := oProgress:maxCount
   DEFAULT nEvery := oProgress:every
...
   // check if a new % Position can be shown
   IF nEvery > 0 .AND. nCurrCount % Int(nEvery) # 0 .AND. ;
      Valtype(nMaxCount) = 'N' .AND. nCurrCount < nMaxCount
     RETURN nil
   ENDIF
   
   // here Code to "show" new % Position

and here you find Express++ Progressbar x:\exp20\Source\Dclipx\_dcclass.prg

Code: Select all

CLASS DC_XbpProgressBar FROM DC_XbpProgressBarSuper, DC_XbaseParts
...
METHOD DC_XbpProgressBar:init( oParent, oOwner, aPos, aSize, aPres, lVisible, oGetList )
...
IF Valtype(oGetList) == 'O'
   ...
   xOptions := aGetListItem[xGETLIST_OPTIONS]
   ...
   DEFAULT xOptions[1] := 1
   DEFAULT xOptions[2] := .f.  // Show Percentage box
   DEFAULT xOptions[3] := 1
   DEFAULT xOptions[4] := .f.  // Vertical


   ::every := Int(xOptions[3])
   ::maxCount := xOptions[1]

if you do not override oProgress:every, which is default 1, Progressbar will "show" every Time.

say nMaxCount := 1000000 but Percent is only from 0-100 -> nEvery := nMaxCount/100
you just need to "show" when new % is reach ... 100 times not 1000000

p.s. i think my native (green) Progressbar Limit is nMaxCount := 32K so i have

Code: Select all

   xMax     := Lastrec()
   nEvery   := INT(xMax/100)
   xScale   := xMax*nEvery                   // Scale to 100%

   oProgress:Minimum          := 0
   oProgress:Maximum          := xMax
   oProgress:nScaleMax        := xScale
   oProgress:Increment        := nEvery

[Cliff Wiernik]

What I use for my processing to allow escaping instead of dc_appevent() is to start the process in another thread. In the calling thread, I you have the button to allow escaping. When clicked, it sets the escape option lOK to .T. and then in the called function, running in the separate thread, I have a do while !OK ; ENDDO construct. That has worked very well.

[Eugene Lutsenko]

And where to insert this code?

Code: Select all

   xMax     := Lastrec()
   nEvery   := INT(xMax/100)
   xScale   := xMax*nEvery                   // Scale to 100%

   oProgress:Minimum          := 0
   oProgress:Maximum          := xMax
   oProgress:nScaleMax        := xScale
   oProgress:Increment        := nEvery

I tried to implement a similar idea in his version of the progress bar, but much more primitive way. Now I see that in the way not failed.

[Eugene Lutsenko]

What I use for my processing to allow escaping instead of dc_appevent() is to start the process in another thread. In the calling thread, I you have the button to allow escaping. When clicked, it sets the escape option lOK to .T. and then in the called function, running in the separate thread, I have a do while !OK ; ENDDO construct. That has worked very well.

And how do these different threads?

[Cliff Wiernik]

This is what I do.

Code: Select all

//Main procedure.

//Defined a pushbutton with an ACTION clause bStart:

  DCADDBUTTON PARENT oToolBar CAPTION {|| IIF(d_lRunmode,'S~top','S~tart') } ;  // Start/Stop Watch Button
    ACCELKEY {Asc('T'),Asc('t')} ;
    ACTION bStart ;

//Code block for bStart

  bStart  := { || IIF( !lRunmode, ;
                        ( lRunmode:=.T., DC_GetRefresh(GetList),           ;
                          GuiRun({|| S_StartProcess(@lRunMode,GetList)})                ; // Starting a new thread...
                        ),                                                    ;
                        ( lRunmode:=.F.,           ;
                          DC_GetRefresh(GetList) ) ) }                           


FUNCTION S_StartProcess(lRunMode,aMainGetlist)

  DO WHILE lRunmode

..... // do your processing
.....
.....

  ENDDO

//This keeps the main dialog responsive to processing so you can click the pushbutton and change the lRunMode Value.

// Function to start the new thread and call function to do your work.  Note, in your thread prior to starting and calling the function, you may need to configure your data access if using ADS, etc.

FUNCTION GuiRun( bBlock)

    oThread := Thread():new()
    sleep(50)
    oThread:start({|| eval(bBlock))})

RETURN NIL