Bug #1603

Feature #964: === GUI ===

GUI: Cancel job is not working anymore after the refactoring of ProgressHandler, GUI real-time performance is heavily affected too

Added by pospelov about 4 years ago. Updated about 4 years ago.

Status:ArchivedStart date:05 Sep 2016
Priority:NormalDue date:
Assignee:wuttke% Done:

0%

Category:-
Target version:Sprint32

Description

Problem I: cancel job is not working

How to reproduce:

  • start new GUI
  • drag and drop sample to sample canvas, use "Interference 2D paracrystal" as a sample which requires a lot of CPU
  • in InstrumentView define detector 200x200 channels to make the simulation run even longer
  • in SimulationView start simulation
  • go to JobView, hover the mouse on running job, press cancel sign

Simulation should stop immediately, partly simulated image should be shown

Problem II: GUI performance is two times slower wrt 1.6.1

There is a huge performance degradation in GUI because of (I think) refactored ProgressHandler.

How to check:
  • Create sample in GUI "Cylinders and prisms", set detector 300x300
  • Run simulation, check simulation duration (lower left corner of JobView)
Results:
  • new ProgressHandler - 740msec
  • 1.6.2 release - 370msec

Why ProgressHandler?

  • I have commented code in ProgressHandler::incrementDone, make it only return true. Results were:
  • new ProgressHandler - 340msec
  • 1.6.2 release - 350msec

I think that the reason is either the cost of

    static std::mutex single_mutex;
    std::unique_lock<std::mutex> single_lock( single_mutex );

or (less likely) threads blocking each other on the way to report ProgressHandler every tiny change in progress.

Earlier, progressHandler was splitted on two parts (ProgressHandler itself with mutex, and ProgressHandlerDWBA without mutex). This was done intentionally to avoid aforementioned problem.

History

#1 Updated by pospelov about 4 years ago

  • Description updated (diff)

#2 Updated by pospelov about 4 years ago

  • Subject changed from GUI: Cancel job is not working anymore after the refactoring of ProgressHandler to GUI: Cancel job is not working anymore after the refactoring of ProgressHandler, GUI real-time performance is heavily affected too

#3 Updated by wuttke about 4 years ago

  • Assignee set to wuttke
  • Parent task set to #964

let me try ...

#4 Updated by wuttke about 4 years ago

  • Status changed from Sprint to Resolved

Resolved in 27f8c9d (pull request 14). Cancellation works. Slow-down cannot be confirmed.

#5 Updated by wuttke about 4 years ago

  • Status changed from Resolved to Sprint
  • Gennady clearly sees slow down when comparing with 'master' unrelated with progress handler
  • Reaction to cancellation is too slow fixed in 9cd6f2b

#6 Updated by wuttke about 4 years ago

TODO: simplify! Since we query progess->alive() very often, there is no more need for the same information to be transmitted as return value of the callback function.

#7 Updated by wuttke about 4 years ago

  • Status changed from Sprint to Resolved

Greatly simplified in 333338ad8989, and display of partial results restored. This should fully resolve the issue.

#8 Updated by herck about 4 years ago

  • Status changed from Resolved to Archived

Also available in: Atom PDF