Performance Question Cancel The title field is required!

1. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   27 Jul 2023

   Link to this post

   We have built our BE over the last 5 years and are using with our GUI for .NET front end. It works great.
   
   We are now looking to use the same BE's for imports that we have that are currently going direct to the DB. We want to use the same validation we have added in the BE. We have found that using the BE for the imports will be about 6-7 times slower. The imports will read an XML, JSON or CSV into a dynamic PDS and then call a business task on the backend to process. We have tried using the datasetmodel class or just using the TT and retrieving using FetchDataRequest with similar results.
   
   We are testing this in 12.7 with compiled .r code. 
   
   The times mentioned above is the actual time to process all the records on the backend.
   
   Is this expected?
2. Mike Fechner

   

   319 posts
   Registered:
   14 Sep 2016
   28 Jul 2023 in reply to Roger Blanchard

   Link to this post

   Hi Roger,
   
   this is difficult to answer without understand how the import routine has previously been written - but assuming that was reading text files and doing straight CRUD (FOR EACHes etc) to the database, it's not surprising that the Business Entities and Dataset Models are slower. 
   
   OERA (or any application model that suggests single-responsibility and reusability) is not primarily there to make the application run faster. Spaghetti code is usually the fastest way to solve a problem, the fastest way to initially implement the code and the fastest way to execute the code. 
   
   But a nightmare in maintenance ...
   
   So it's fair to assume that structuring code in more code units brings overhead. Business Entities in addition provide more overhead because data is read into temp-tables before you consume it and you create/update data in temp-tables first and then populate the changes into the database. 
   
   There's just sooo much more going on.
   
   There are alternative methods or data access we use when reusability (of calculated fields) is not that relevant. The business entity designer can generate repositories for value objects. That's a more lightweight method of reading data. It on purpose dismissed the separation between business logic (BE) and data access.It's a faster way to implement calculated fields for instance. 
   
   Having that said, you might want to review your startup parameters. A large -D, -q and -reusableObjects can significantly improve performance of OOABL applications and especially the SmartComponent Library. 
   
   Temp-Tables and ProDatasets benefit from a large -Bt and -tmpbsize 8
   
3. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   28 Jul 2023 in reply to Mike Fechner

   Link to this post

   Hello Mike,
   
   Thanks for the comments and we will try the startup parameter suggestions.
   
   Will I see you at PUG in November? 
4. Mike Fechner

   

   319 posts
   Registered:
   14 Sep 2016
   28 Jul 2023 in reply to Roger Blanchard

   Link to this post

   Of course!