2018-09-25 13:12 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001486Orfeo Toolbox (OTB)Generalpublic2018-01-11 17:43
Reporterpoughov 
Assigned Togpasero 
PriorityurgentSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
Summary0001486: Monteverdi takes too long to load OTB applications
DescriptionMonteverdi takes too long to load the OTB applications widget. On my lenovo X270 (a modern laptop) it takes about 27 seconds. It should be a near instantaneous UI action (<0.5 sec) like other widgets.

I understand it is because it loads all OTB dlls. But this behavior is the object of this bug and needs to be fixed. Perhaps load only the application that the user needs (instead of all 90+)?
Steps To ReproduceIn Monteverdi: Display -> OTB Applications
(tested on win64 binary package)
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0004454

gpasero (administrator)

The main issue here is : we need to get the tags and long name for each application in order to build the tree in the UI.

I agree it take some time to load every application, but for the moment I don't see alternatives.

~0004484

grizonnetm (administrator)

I've tested also to load otb applications on a lenovo X270 Windows 10 64b with the standalone binary package.

OTB 6.2: 27 sec
OTB 6.4 (package generated the 08/01/2017 7:56): 1 or 2 sec

So I think that the problem does not appear anymore with otb 6.4 but it would be cool to identify the root cause...

~0004494

poughov (administrator)

Last edited: 2018-01-10 10:12

View 2 revisions

Originally reported for 6.2. I just tested also in 6.4. Almost instant on my win64 machine (< 1 sec).

~0004496

grizonnetm (administrator)

Does somebody understand the root cause of these performance issues with otb 6.2 binary package on windows?

~0004503

gpasero (administrator)

By looking at the diff, my first guess is : replacement of TimeProbe by StopWatch. Laurentiu reported performance regression (and instanciation cost). Each Application had a TimeProbe in its attributes, now replaced by a StopWatch.

My second guess would be : a better implementation of List parameters, but the impact should be small as not every application use this kind of parameter.

~0004504

gpasero (administrator)

Closing this bug, already solved by previous improvements.
+Notes

-Issue History
Date Modified Username Field Change
2017-12-06 12:32 poughov New Issue
2017-12-14 12:34 grizonnetm Priority normal => urgent
2017-12-19 17:29 gpasero Note Added: 0004454
2018-01-08 14:54 grizonnetm Note Added: 0004484
2018-01-10 10:11 poughov Note Added: 0004494
2018-01-10 10:12 poughov Note Edited: 0004494 View Revisions
2018-01-10 10:37 grizonnetm Note Added: 0004496
2018-01-11 17:38 gpasero Note Added: 0004503
2018-01-11 17:43 gpasero Assigned To => gpasero
2018-01-11 17:43 gpasero Status new => closed
2018-01-11 17:43 gpasero Resolution open => no change required
2018-01-11 17:43 gpasero Note Added: 0004504
+Issue History