Avoid building element when its visibility evaluates to false

[dariobella]

I recently built an excel report that has different sheets, and through report parameters we let the user decide which sheets should be included in the final result. After noticing that the report generation always lasted the same amount of time no matter the parameters and doing some logging I found out that altough the visibility is set to false

and the table doesn't show up in the output, it is still generated by birt (all of the scripts are being executed).
Currently I solved the problem in this way:

if (visible === false) {
    reportContext.getDesignHandle().findElement("table_name").drop()
}

But I wanted to ask if there's an easier way, like a setting that avoids the "building" of elements that have their visibility set to false. Cause I would argue that in the vast majority of cases, if one hides an element in the report it would also be preferred not to spend resources in its generation. For this case in particular, since we're talking about a few very large excel tables (one took up almost 20s with the query etc.), adding this code once per table is not a big deal, but in other very dynamic reports, knowing that in order to not waste resources I should add this code for every element where I set a visibility expression is definitley not ideal

[hvbtup]

I would argue that in the vast majority of cases, if one hides an element in the report it would also be preferred not to spend resources in its generation.

At the very first glance, yes.

But if you take a closer look, there are often cases when you need to execute the dataset to decide if you want to show the layout item or not, for example, to hide a table (including header and footer!) if there are no rows.
And there are also cases when you have layout items which just perform logic and which are always hidden.

Both use-cases depend on the implementation as it is now.

What you should do instead: Filter the data!

So you should use either a filter condition based on the parameter "host_template_sheet" in the layout item (eg the table) that is bound to the data set. Or - much better - you can use a bind variable based on the parameter "host_template_sheet" in your data set, e.g. in an SQL WHERE condition. That way you only select the data from the DB if you really need to show it.

[hvbtup]

Mainly because by doing that I'd still be opening the database connection and executing the query

This is irrelevant in practice. If your report should produce anything useful, it will need a DB connection anyway.
And SQL databases are very quick in noticing an that when a condition where :some_parameter = 1 ( or where ? = 1) is specified and the :some_parameter bind variable value is 0, the query cannot find anything, so the performance overhead (1 DB roundtrip and query parsing) is neglectable in practice (some milliseconds usually).

And also because of mantainability: I'd have to modify the dataset and the element instead of only one script.

Yes. But you decide if it's worth the effort for performance reasons.

[dariobella]

This is irrelevant in practice. If your report should produce anything useful, it will need a DB connection anyway

Not in my case, as the only table that is always present in the output is bound to a scripted data source that gets its data from an external endpoint. This means that if the user de-selects all the sheets that are getting data from the DB and has only the ones that get data from the endpoint, I won't need to connect to it.

But you decide if it's worth the effort for performance reasons

Well comparing the logs between the solution of modifying the datasets to return 0 rows + visibility expressions:

initialize
Host Inventory onPrepare
Host Templates onPrepare
Host Macros onPrepare
Host History onPrepare
host_inventory beforeOpen
host_inventory onFetch
...
host_inventory onFetch
Host Inventory onCreate
Host Inventory onRender
host_inventory afterClose
host_templates beforeOpen
Host Templates onCreate
Host Templates onRender
host_templates afterClose
host_macros beforeOpen
Host Macros onCreate
Host Macros onRender
host_macros afterClose
Found JDBC driverinfo extension: driverClass=org.apache.derby.jdbc.EmbeddedDriver, connectionFactory=null
Found JDBC driverinfo extension: driverClass=org.eclipse.birt.report.data.oda.sampledb.Driver, connectionFactory=org.eclipse.birt.report.data.oda.sampledb.SampleDBJDBCConnectionFactory
Loaded JDBC driver class in class path: org.mariadb.jdbc.Driver
host_history beforeOpen
Host History onCreate
Host History onRender
host_history afterClose
Task finished, duration: 8292ms

And the one where I only use the reportContext.getDesignHandle().findElement("table_name").drop():

initialize
Host Inventory onPrepare
Host Templates onPrepare
Host Macros onPrepare
Host History onPrepare
host_inventory beforeOpen
host_inventory onFetch
...
host_inventory onFetch
Host Inventory onCreate
Host Inventory onRender
host_inventory afterClose
Task finished, duration: 7799ms

You can see what my intended behaviour was. So for both maintainability and performance I think the second one is still better, I just thought that maybe I'd be able to do it without scripts (that's why I was asking in the first place)

[hvbtup]

If you are using a scripted data source, then you can of course use the report parameter in the open and fetch events of the scripted DS to directly return zero rows and avoid accessing the DB.

[dariobella]

By "modifying the datasets to return 0 rows" I meant exactly that, that's what I did in the first log.
Maybe I should've added more context: those are both executions of the exact same report with the exact same output. The only table that it contains is the Host Inventory table, which is based on a scripted data set. All the parameters for the other tables (Host Templates, Host Macros and Host History) are set to false, the first two are also based on a scripted data set, the last one on a normal one that accesses the DB.
The goal was, like in the second execution, that after rendering the first table and closing the dataset, that the report would immediately finish (as it has nothing else that it needs to do)

[hvbtup]

Your test shows 7.8 and 8.3 seconds for the different versions. Based on a single test run, I think the difference is not really significant. If the performance difference of 0.5 seconds is reproducible, then I guess this is basically the time to connect to the DB. AFAIK it is not possible to avoid this using scripting.