When it comes to database queries, for a couple of versions List & Label already checks for the identifiers/fields that are actually used in the project and only queries and passes those. However, this information was not available table instance specific, only globally for the database table itself. A simple example: if you printed the same table twice, once using the fields “FirstName”, “Name”, “Address” and “City” and then a chart where you were using “Revenue” and “City”, this makes five identifiers in total (“FirstName”, “Name”, “Address”, “City”, “Revenue”).
Until LL23, the databinding engine will pass the full five identifiers twice to the report, once for the table and once for the chart. LL23 is now able to differ between both objects and pass just the right data. This greatly lowers the load on your database server and also saves a few gazillion API calls, depending on how large your database is. If you’re writing your own data provider, you can profit from this feature with just a few changes as well.
Another giant performance boost is related to this. If using report parameters (e.g. a parameter “City”) to filter the data, in LL22 the whole “broad” record would have been passed even three times. LL23 can recognize that the parameter just needs distinct values and will optimize the query on the database side already. So instead of a
SELECT FirstName, Name, Address, City, Revenue FROM Customers
and collecting the distinct cities in the print engine we’ll just send a
SELECT DISTINCT City FROM Customers
which performs infinitly faster.
Seeing is believing: The animations below show a comparison between LL22 and LL23 for exactly the same report.
Related to this topic, we also dramatically improved the memory footprint of the crosstab. You’ll recognize this especially when printing crosstabs that span multiple shadow pages – LL23 will require only approximately half of the memory that LL22 used.