in the BIRT Reporter I often design tables which contains around 500 cells which have different text or numeric columns in them, as well as 6 structure cells as dynamic images. Also, all these cells are also colour highlighted using 3 highlight rules per cell based on a column value. So that's maybe around 1500 highlight rules altogether.
the trouble is, if I make any changes to the Knime table in the workflow such as adding an additional column into the dataset, when I then go back to the BIRT reporter it mentions there are changes that need to be applied and updated and when I choose ok it then proceeds to take around 4 hours before the Knime application becomes responsive again. It just seems to hog cpu power for hours on end, before I can start to use the BIRT report designer again.
i can not see why a modest Knime table of 500 columns and probably 10 rows going into the table to report node, and then 500 cells in the BIRT designer as a table should require so much cpu time when the Knime workflow table gets very minor changes made to it.
Any fixes to this, numerous other colleagues are experiencing this.
its unacceptable that you add one new column into the Knime table that goes to the reporting node and then have to wait 4 hrs or more before you can do any more work.
This is crazy why a table layout should require 4 hrs of computational power to resolve.
I didn't experienced slow BIRT report generation.... until this morning. I have a workflow with just 2 small tables to be imported into the reporting system. I opened up the report and after confirming to update, the whole KNIME get frozen with the message “Operation in progress...”.
Is this the problem you're mentioning here? Did you understand when and why this happens? I worked with similar data and I never experienced it before. I don't know what to do. It seems really stuck. Do I have to wait?
Yes it's always after confirming to update and it freezes for a unspecified time. I personally found that this freeze can vary from 1hr up to 9 hours!! In the tables I have.
These long wait times for me always occur when the number of columns in the table changes, this always give these really lengthy wait times. You simply have to wait until Knime becomes responsive again
its making the whole process of using report designer close to unusable. Quite a number of my colleagues are now experiencing this, so it's not just me!
my colleagues are experiencing it on much smaller tables than me, with around 60-100 cells and no highlighting rules applied
I am also experiencing this issue. Last week it was taking 2-3 hours before knime became responsive again and the update was complete. Yesterday I gave up after 8 hours and restarted knime. Today I have tried again and after 5.5 hours I am still waiting . . . . .
I'm experiencing such a problem using the current KNIME version (2.12.0). I let my system updating during more than 36 hours and it didn't finish! This is simply not manageable.
I think that the problem is not related with the dimension of the data table as I have problems also in updating adding a small table of 8 rows & 3 columns. I had a look at the log file and I realized that the process entered in a loop, so I opened up a new forum thread:
(Finally someone from KNIME, sorry for months delay.)
So I tried reproducing this as well. I took a table with 100 rows, ~500 columns of mixed type (numbers, text, images). My report only contained this single table (which, btw, is completely meaningless with 500 columns).
I can see that an additional column in the KNIME table and then switching to BIRT with the fully executed workflow can take long (I killed it after 5min). Debugging this session revealed that CPU time is spent in BIRT code, not KNIME, which makes this tricky to fix for us. You can also verify this by removing any BIRT report element and just applying on an empty report - it's much quicker.
I also tested that behavior with what-will-be-KNIME-3.0, which is based on a newer Eclipse/Birt version. The problem does not present itself then. It's much quicker (milli seconds), so I'm positive the BIRT developers fixed it.
Can you be more concrete? There were few problems with the report designer not in sync with the workflow (but that errored out early). The rest seems ok and we are not aware of issues with such small tables.
The problem with the small table taking a long time to process seemed to fix itself after Knime was updated and the PC re-booted - chalk that one up to a strange glitch!?
Reporting is still not particularly quick - but at least it is usable now.