Time of swithching between "Edit Mode" and "Results Mode" in RM 4.4

michaelhechtmichaelhecht Member Posts: 89 Maven
With RM 4.4 I've got the problem, that after finishing a workflow the automatic switching between "Edit Mode" and "Results Mode" takes
about 20 to 25 seconds. In RM 4.3 I got it immediately. Curiously in RM 4.3 there was another "time delay" with the plot view, i.e. it took
also about 20 seconds after changing to the plot view until it accepted a change of plotter types, e.g from scatter to scatter matrix.

On my notebook I didn't observe this strange effect, but it might exist. Changing the Java VM didn't change anything. Has anyone
any idea what workaround could help me?

Both computers are running Win XP professional with all patches. The laptop is an older single core CPU the desktop PC a new dual core
CPU.

Answers

  • IngoRMIngoRM Administrator, Moderator, Employee, RapidMiner Certified Analyst, RapidMiner Certified Expert, Community Manager, RMResearcher, Member, University Professor Posts: 1,751 RM Founder
    Hi,

    With RM 4.4 I've got the problem, that after finishing a workflow the automatic switching between "Edit Mode" and "Results Mode" takes
    about 20 to 25 seconds. In RM 4.3 I got it immediately.
    Hmm, we cannot reproduce this behaviour here although I have to admit that we got another mail from a user who also reports that the change to the result view takes more time now. This is hard to fix since we cannot reproduce it but maybe we can try to get more information to find the reason for this behavior. Therefore, I have some questions:

    1. Does this delay also occurs if no results are produce at all, i.e. for an empty process or after removing the outputs with the IOConsumer?

    2. Does this delay only occurs for specific output types or in general independent of the types of the produced IO objects.

    3. Do the delay occurs before or after the "bing" indicating the end of the process / before or after the statement of the message "Process finished" in the logging viewer at the bottom of the window?

    4. Do you use the RapidMiner Windows installer pack or the zipped version in combination with your own Java installation?


    Probably your answers will give us a hint for starting our search and we would highly appreciate if you could provide us those information.

    Curiously in RM 4.3 there was another "time delay" with the plot view, i.e. it took
    also about 20 seconds after changing to the plot view until it accepted a change of plotter types, e.g from scatter to scatter matrix.
    This delay is by design since some of the plotters (especially the 3D ones need some time for initialization which is done in parallel).

    On my notebook I didn't observe this strange effect, but it might exist. Changing the Java VM didn't change anything. Has anyone
    any idea what workaround could help me?

    Both computers are running Win XP professional with all patches. The laptop is an older single core CPU the desktop PC a new dual core
    Maybe you have performed a different process (delivering different results) on your notebook? We also use Windows XP professional here on both single, dual, and quad core CPUs and noted no difference with respect to this change (at least we do not get 20-25 seconds delay, maybe up to 3 seconds only).

    Cheers,
    Ingo
  • michaelhechtmichaelhecht Member Posts: 89 Maven
    Puh ... I'm not the only one with this problem ...

    This gives me new energy to make some trials under different conditions. I will report the results as soon as possible.

  • IngoRMIngoRM Administrator, Moderator, Employee, RapidMiner Certified Analyst, RapidMiner Certified Expert, Community Manager, RMResearcher, Member, University Professor Posts: 1,751 RM Founder
    Hi again,

    yes, for a start the answers to the four questions above would probably give us a good hint what might happen on those systems. Probably some deadlock but why this should be more likely on some systems than on others: I don't know yet...

    Thanks in advance for your help. Cheers,
    Ingo
  • michaelhechtmichaelhecht Member Posts: 89 Maven
    Hi Ingo,

    I tried some different approaches. Here are the results:

    1. Switching is delayed (blocked) even if only a file is loaded (CSV)
    2. Switching is delayed (blocked) if IOConsumer is placed at the end of workflow
    3. Switching is NOT blocked if an empty workflow is executed
    4. System is always "blocked" after ping, i.e. after workflow has finished
    5. While RM waits for switching to Results Mode no input is accepted (no mouse-click)
    6. I used the installer but replaced the jre-subdirectory by different Java runtimes (down to 1.5.0x) the problem remained

    That is the current state of the investigation. Maybe this helps. If not I can check other things.

  • IngoRMIngoRM Administrator, Moderator, Employee, RapidMiner Certified Analyst, RapidMiner Certified Expert, Community Manager, RMResearcher, Member, University Professor Posts: 1,751 RM Founder
    Thanks for the information.

    Here are some new questions:

    Switching is delayed (blocked) even if only a file is loaded (CSV)
    I assume that nothing else is done but loading this file, right? So the process consists of only one operator?

    And: does the data contain

    - numerical values only,
    - nominal values only,
    - both types

    ?

    While RM waits for switching to Results Mode no input is accepted (no mouse-click)
    This is interesting! This points to a GUI deadlock.

    Thanks again and cheers,
    Ingo
  • michaelhechtmichaelhecht Member Posts: 89 Maven
    Hello,

    I created a file containing 30 rows in two columns with x = 1 .. 30 and y = x**2 and stored it as *.csv.

    Again only loading and waiting for a mode change took about 25 seconds after reading has finished.
    Then I changed both columns to nominal (still 30 rows) and the same happened.
    I changed first column to integer and second to nominal, the same happened.

    Afterwards I stored the data as *.xls and used the ExcelExampleSource. Surprisingly now the GUI directly changes
    to results mode and is then blocked, i.e. only the tab "Data Table" is displayed but empty for the next 25 seconds.

    Unfortunately this doesn't seem to be reproducible, i.e. later I got the same as with CSV.
    Using the AccessExampleSource I got the same behaviour.
    With ARFF I got the same behaviour.

    Perhaps depending on the "timing" of the GUI or Java VM, either the GUI "deadlock" happens prior to switching to results mode or directly afterwards.

    This is one of the workflows:
    <operator name="Root" class="Process" expanded="yes">
        <operator name="ExcelExampleSource" class="ExcelExampleSource">
            <parameter key="excel_file" value="C:\temp\Simple.xls"/>
        </operator>
    </operator>


    I don't think this description can help you, but nevertheless this is all I can offer.

    Next week I'm in holidays so I cannot answer any posting to the forum.

    Bye,

    Michael
  • IngoRMIngoRM Administrator, Moderator, Employee, RapidMiner Certified Analyst, RapidMiner Certified Expert, Community Manager, RMResearcher, Member, University Professor Posts: 1,751 RM Founder
    Hi Michael,

    thanks for your efforts - they really help! At least we can now rule out data set specific errors or the changes in the meta data viewer for displaying nominal values.

    But still I did not yet find the problem. I tried exactly your setup (x=1..30 and y=x**2; 30 rows) and have to wait between 1 and 2 seconds for the first time (the 3D engine for the 3D plot needs some time for initialization) and less than 1 for following runs. But at least for one time I had the same effect of about 1 second only the empty tab and then the tab was filled later. Weird, but maybe the same effect you experience but "on speed".

    Thanks to your detailed report we can now rule out many of the changes between 4.3 and 4.4 we will try to check the remaining and GUI related ones since I do not think that it has something to do with the data set etc.

    We will try to find a reason. Nice vacation and thanks again,
    Ingo

Sign In or Register to comment.