You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
VickieLynch opened this issue
May 7, 2015
· 3 comments
Assignees
Labels
FrameworkIssues and pull requests related to components in the FrameworkStaleThis label is automatically applied to issues that are automatically closed by the stale bot
Looking at the performance tests, I’ve noticed that the change to run IntegrateEllipsoids in parallel has yielded an decrease in speed. See http://builds.mantidproject.org/view/Tests/job/performance_tests_master/Master_branch_performance_tests/ MDAlgorithmsTest.IntegrateEllipsoidsTestPerformance.test_execution_events
Conceptually, doing this part of the processing in parallel should not have had this effect. For 3.5 do you think you could profile the performance tests on this algorithm to find out where the real bottle necks are?
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If you feel this is incorrect please comment to keep it alive, with a reason why.
To prevent closure, e.g. for long-term planning issues, add the "Never Stale" label.
stalebot
added
the
Stale
This label is automatically applied to issues that are automatically closed by the stale bot
label
Feb 24, 2021
FrameworkIssues and pull requests related to components in the FrameworkStaleThis label is automatically applied to issues that are automatically closed by the stale bot
This issue was originally TRAC 11724
Looking at the performance tests, I’ve noticed that the change to run IntegrateEllipsoids in parallel has yielded an decrease in speed. See http://builds.mantidproject.org/view/Tests/job/performance_tests_master/Master_branch_performance_tests/ MDAlgorithmsTest.IntegrateEllipsoidsTestPerformance.test_execution_events
Conceptually, doing this part of the processing in parallel should not have had this effect. For 3.5 do you think you could profile the performance tests on this algorithm to find out where the real bottle necks are?
The text was updated successfully, but these errors were encountered: