Dynamics Business Central / NAV Developer Digest - Vol. 440
ArcherPoint’s Developer Digest focuses on Microsoft Dynamics 365 Business Central and Dynamics NAV development. This week’s volume is focused on better AL design to improve Business Central performance using built-in data structures.
The Dynamics 365 Business Central community comprises professionals devoted to advancing the success of their customers. Developers, project managers, and consultants collaborate to share helpful information across blogs, forums, and social media sites. From discovering new solutions to finding answers to complex issues, these dedicated individuals are constantly sharing their knowledge with others. At ArcherPoint, we recognize and appreciate this highly engaged community’s creativity, hard work, and collective intelligence. To ensure all users can benefit from their expertise, we want to share their wealth of information with everyone.
Use built-in data structures to improve Business Central performance
Kyle H offered the following advice for AL design to improve Business Central performance:
AL comes with built-in data structures that have been optimized for performance and server resource consumption. Make sure that you are familiar with them to make your AL code as efficient as possible.
When working with strings, make sure to use the TextBuilder data type and not repeated use of the += operator on a Text variable. General guidance is to use a Text data type if you concatenate fewer than five strings (here the internal allocation of a TextBuilder and the final ToText invocation is more expensive). If you need to concatenate five strings or more or concatenate strings in a loop, then TextBuilder is faster. Also, use a TextBuilder data type instead of BigText when possible. For more information, see TextBuilder Data Type.
If you need a key-value data structure that is optimized for fast lookups, use a Dictionary data type. For more information, see Dictionary Data Type.
Use a List data type if you need an unbound “array” (where you would previously create a temporary table object). For more information, see List Data Type.
Use the Media or MediaSet data types instead of the Blob data type. The Media and MediaSet data types have a couple advantages over the Blob data type when working with images. First of all, a thumbnail version of the image is generated when you save the data. You can use the thumbnail when loading a page and then load the larger image asynchronously using a page background task. Second, data for Media and MediaSet data types is cached on the client. Data for the Blob data type is never cached on the server; it’s always fetched from the database.
Pranav J added: I agree with using the Dictionary and Lists over temporary record variables, they are much more efficient than adding to and retrieving data from temporary record variables.
If you can work with Json structures and Json Objects, tokens, etc., then that is another good option to store temporary run-time data, including key-value data, over the temporary record variables.
Given these options, a temporary record variable should be the last option to store the run-time data, and if a temporary record variable is the only solution, then it is recommended to create new table of Temporary table type and use that to store run time data rather than creating a temporary record variable of an existing table.
Tables with the Temporary table type do not get created in SQL, so they are faster. And since custom objects are free in BC/AL, it does not cost anything to the user when you create new table!
Interested in Dynamics NAV and Business Central development? Be sure to see our collection of NAV/BC Development Blogs.
Read “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV and Dynamics 365 Business Central.