Slow Performance with Data from Object

Our client is using combit LL27 from NuGet and are expreriencing same issue. Slow startup of LL and slow pdf generation.
We’re feeding data to report manually using AddFromObject which for a POCO object takes up 7-8 seconds. One invoice printout takes 30 seconds.
The customer migrated their platform to Windows Server 2019 / Windows 10 on Citrix. The programming language used is C# on .NET Framework 4.8.

I hope somebody can point me in the right direction.

Is there any way to change the data supply to using an ObjectDataProvider? Most performance issues with object data sources turn out to be caused by complex hierarchies that tend to be deeper than expected. This can be fine-tuned with the provider.

If that is not feasible, could you share the definition of your POCO object? We could then try to reproduce the issue.

I will have to investigate migrating to ObjectDataProvider. The solution is from LL16! And updated over the years to new LL versions.
My problem was showing when the OS was upgradet from 2008 R2 to 2019.

The POCO definition og my object is:

ref Invoice
	string cardCodeField
	string cardNameField
	string addressField
	string shipToCodeField
	string address2Field
	string cntctCodeField
	string cntctNameField
	string numAtCardField
	string currencyField
	string docNumField
	string docStatusField
	System.DateTime docDateField
	System.DateTime docDueDateField
	string docTypeField
	string slpCodeField
	string slpNameField
	string commentsField
	double docTotalField
	double docTotalFCField
	double vATField
	double vATFCField
	double discPrcntField
	string trnspCodeField
	string trackNoField
	string blockDunnField
	string paymGroupField
	string paymGroupNameField
	string projectField
	string paymentRefField
	string indicatorField
	string licTradNumField
	string comesFromField
	string ownCompanyField
	string ownPhoneField
	string ownFaxField
	string ownTaxIdField
	string ownPBSNumberField
	string ownDflBnkCodeField
	string ownDflBnkAcctField
	string ownDflBranchField
	string ownStreetField
	string ownZipCodeField
	string ownCityField
	string vATCodeField
	string sWIFTField
	string iBANField
	List<InvoiceLine> linesField
	dynamic OrgInvoice
	dynamic OrgCreditnote 
	InvoiceType (enum) Type 
	string BaseInvoice
	int errCode
	string errString
	string VirkInfo
	bool IsPerson
	string AddressCountryISO
	string AddressCity
	string AddressZipCode
	string AddressStreet
	string Address2Country
	string Address2City
	string Address2ZIP
	string Address2Street
	string CustomerRef
	string PurchOrderFormNum

ref InvoiceLine
	InvoiceLineType lineTypeField
	string discLineField
	string printLineField
	double discountPriceField
	string discItemCodeField
	string itemCodeField
	string descriptionField
	double quantityField
	string currencyField
	double priceField
	double priceFCField
	double lineTotalField
	double lineTotalFCField
	double discPrctField
	double vATField
	double vATFCField
	string textLineField

At first glance, it doesn’t look that complex. It should not take up to 7-8 seconds.

To be able to analyze the behavior more precisely, we would like to ask you to create a minimized sample for us. Please create a new Supportcase and upload the sample.

We will of course share a possible solution for all users here in the forum.

Thank you very much.

I tried this weekend to make a prototype, and actually I have some properties in the “POCO” that extend into another system (including web requests, but these properties aren’t used in LL).
In LL26 on Windows 2008R2 this wasn’t an issue.
In LL26 and LL27 it becomes an problem. How does LL extract the data from the POCO?
And is it possible for me to hide properties by modifier for LL?

I recognize that Windows 2019 includes Defender with real-time protection and that no exclusion is set up for my program.
If LL reads the not-so-POCO properties and thereby makes web requests it could be Defender scanning all the time.

By the way I can confirm my plain POCO is read immediately in LL in the test project I would have send to you if that wasn’t the case :wink:

You could add the Browsable(false) attribute to the properties in question :slight_smile:.

© combit GmbH