|Functionality||After||Before||Result of changes|
||Improved server cluster scalability for the following cases:
Reduced amount of RAM used by 1C:Enterprise server to run applications that utilize batch queries.
|Poor server cluster scalability was observed in the following cases:
1C:Enterprise server used a significant amount of RAM to run applications that utilized batch queries.
|Improved 1C:Enterprise server cluster scalability.|
||Faster 1C:Enterprise script execution by 1C:Enterprise server.||The performance of 1C:Enterprise script execution by 1C:Enterprise server was insufficient.||Optimized 1C:Enterprise script execution by 1C:Enterprise server.|
|Data composition system.
||Faster initialization of data composition settings composer by source of available data composition settings when using schemas with a large number of calculated fields.||The performance of initialization of data composition settings composer by source of available data composition settings when using schemas with a large number of calculated fields was insufficient.||Improved performance of data composition system initialization in several scenarios.|
||Reduced amount of RAM used by 1C:Enterprise server to run applications that utilize batch queries.||Significant amount of RAM was used by 1C:Enterprise server to run applications that utilize batch queries.||Optimized amount of RAM used by 1C:Enterprise server to run batch queries.|
||Optimized updating of local cache of configuration storage when putting objects into storage and getting objects from storage.||The performance of putting objects into configuration storage and getting objects from storage was insufficient.||Putting objects into configuration storage and getting objects from storage is now faster.|
||Implemented retention of module search index between Designer sessions. Reduced time required for initial generation of module search index. Significantly reduced time required for module search index generation during all subsequent Designer sessions. Running Designer with command-line option /ClearCache clears the module search index.||Module search index was not retained between Designer sessions. Index generation required significant time.||It is now easier to work with large configurations.|
||When searching for strings in a value table using the FindRows() method, the index is only analyzed for column content matches between the search parameters and the index. The relative order of columns in the search parameters or in the index is ignored during the search.||When searching for strings in a value table using the FindRows() method, the index was only used if the relative order of columns in the search parameters matched the index column order.||Using the index to search value tables by multiple columns is now faster.|
||Optimized full-text search index generation and update.||The performance of initial generation and updates of full-text search index was insufficient.||Updating the full-text search index is now faster.|
|Improved processing speed of queries containing keyword DISTINCT that get a large number of records (in file infobases).||Processing speed of queries containing keyword DISTINCT that get a large number of records (in file infobases) was insufficient.||Getting large lists of unique records from file infobases is now faster.|
|Faster deletion of large record sets from file infobases. Faster recalculation of totals for tables with a large number of records in file infobases.||The following operations in file infobases were insufficiently fast:
||File infobases now work faster in some scenarios.|
||Improved performance when getting data displayed as dynamic list with conditional formatting.||The performance of getting data displayed as dynamic list with conditional formatting was insufficientl.||The performance of dynamic lists with conditional formatting is now improved.|
||Faster opening of forms containing dynamic lists with complex queries.||The performance of opening forms containing dynamic lists with complex queries was insufficient.||Forms containing dynamic lists with complex queries now open faster.|
||For dynamic lists, implemented the option to enable or disable getting presentations for values of reference types that are not displayed in the form or are associated with invisible form items. Presentations of key field values for dynamic lists in selection mode are obtained regardless. Implemented dynamic list property GetInvisibleFieldPresentations.
This change is not implemented in 8.3.7 compatibility mode.
|In dynamic lists, presentations were obtained for all reference type values to be sent to client side.||Dynamic lists can now be displayed faster in some cases.|
|Data composition system.
||Optimized RAM usage when composing data composition templates with large queries in data composition schema.||RAM usage when composing data composition templates with large queries in data composition schema was sub-optimal.||Composing data composition templates with large queries in data composition schema now requires less RAM.|
||Slightly improved thin client startup time in file infobases when working with large configurations.||Startup time of the thin client in file infobases when working with large configurations was insufficient.||Startup time of the thin client in file infobases when working with large configurations is now improved.|
||Optimized object lock and release operations in configuration repositories. Changed internal format of locked object data storage for infobases connected to repositories. The data storage format is changed after the data storage optimization operation is completed using the Local repository data usage settings dialog box. This optimization is only available if the configuration was bound to a configuration repository in an earlier platform version. To use the optimized infobase in an earlier platform version, rebind the infobase to the configuration repository in an earlier platform version.||The performance of object lock and release operations in configuration repositories was insufficient.||Working with configuration repositories that store large configurations is now faster.|
||Improved startup time of client applications after dynamic update.||Client applications required longer time to start after dynamic update.||Improved startup time of client applications after dynamic update.|
|Web services and HTTP services.
||Every time a method of a web or HTTP service is called, the compiled service module is cashed.||Every time a method of a web or HTTP service was called, the service module was compiled.||Improved system performace in scenarios that include a large number of web or HTTP services calls.|
|Improved performance of the following accounting register record set operations for infobases running in file mode or in client/server mode with PostgreSQL:
||The performance of the following accounting register record set operations was insufficient in infobases running in file mode or in client/server mode with PostgreSQL:
||Optimized accounting register operations for some DBMS.|
||Optimized query plan generation for PostgreSQL version 9.6.3. This improves the performance of complex queries that use data access restriction templates.
Optimization is available for PostgreSQL versions 9.6.3-2.1C and later.
|In PostgreSQL, performance of complex queries that used data access restriction templates was insufficient, in some cases applications might stop responding during query execution.||Improved performance of PostgreSQL operations initiated from 1C:Enterprise.|