[Isomorphic]

Blama is correct for separate <script src=> tags with the DataSourceLoader servlet. <loadDS> JSP tags are different, in that they inline the DataSource definition into the initial page, not as a separate request.

So for <loadDS> tags, we would expect a very small effect (if even measurable) for combining tags.

However, as noted above, it's usually better to use the <script src=> approach with DataSourceLoader, because it allows the browser to start on other tasks in parallel.

[Blama]

Hi claudiobosticco,

most definitely, otherwise it means MANY network requests and you really don't want that. See also here.

Best regards
Blama

[claudiobosticco]

Hello, I did notice some improvements in speed, but since I also made some application optimizations, I wasn’t sure if the changes were due to the framework as well. After running some tests, I can confirm there’s a noticeable improvement—thank you very much!

Regarding the loadDS tag, can I expect any differences between using a separate tag for each data source versus a single tag with a comma-separated list of data source names as the ID?

[Isomorphic]

Actually, we did make improvements in this area back in March and April. deepClone() now has optimizations in place to avoid Reflection in common cases, and we find that deep cloning of a typical DataSource config now takes around half the time it did previously. However, we have also optimized this particular flow - cloning config for security annotations - so that it no longer does a deep clone at all.

As mentioned, this has all been in place in 13.1 since April, so you should see it spending a lot less time in _cloneConfigForSecurityAnnotations() with 13.1 builds more recent than that

[Isomorphic]

Sorry, this fell through the cracks somewhat. Somebody will take a look soon, and we'll post back on this thread

[claudiobosticco]

Hello, may I ask if there has been some change development in this area?

[claudiobosticco]

Hello, just chiming in to ask if there's some update

[Isomorphic]

Nothing more is needed from you for now - we're going to try to figure out why that Reflection call is appearing in the middle of your DataSourceLoader processing, as it's probably possible for the framework to avoid it.

Note that Reflection can be radically more or less expensive in different environments. One factor is a long classpath with duplicates, so you could look at reducing the cost of Reflection calls if you want.

[claudiobosticco]

Hello, are you investigating this problem, or do you need more debugging by my side?

[claudiobosticco]

which so far seems relative to fields with validators using <applyWhen>, or to fields with custom simple types which I have defined, ie like:

actually they're relative to fields with validators using <applyWhen>, and to the loading of my custom Simple Types xml definitions

[claudiobosticco]

as a side note, only on first load I've got a bunch of logs like these:

WARN DefaultValidators Field 'name' not found in data source 'ServerObject'
WARN DefaultValidators Field 'name' not found in data source 'AdvancedCriteria'
WARN DefaultValidators Field 'name' not found in data source 'Criterion'

which so far seems relative to fields with validators using <applyWhen>, or to fields with custom simple types which I have defined, ie like:

<SimpleType name="trimText" inheritsFrom="text" editorType="TextItem">
    <validators>
        <validator type="serverCustom">
            <serverObject lookupStyle="new" className="com.my.types.TrimDMI"/>
        </validator>
    </validators>
</SimpleType>

[claudiobosticco]

Nope to both questions.

Actually I see many calls to Reflection.findMethod, as in this debugger screenshot:



smartClient version is 'v13.0p_2023-12-08/Enterprise Deployment'

[Isomorphic]

Hmm, there normally should not be a Reflection call in that codepath. Do you have any custom (non-framework) properties in your .ds.xml definitions - anything that isn't just a simple String value? Or do you do anything like use DSField.put() to put custom objects into your fields or DataSource definition (note this wouldn't be valid, due to pooling).

[claudiobosticco]

Hello, about dataSource pooling, what I see is a log like this, for every dataSource, on first load:

DEBUG PoolableDataSourceFactory Created DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712' and assigned it to thread https-jsse-nio-8443-exec-8
DEBUG PoolableDataSourceFactory Created DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712' in the pooling flow
DEBUG PoolableDataSourceFactory Activated DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712'
DEBUG PoolableDataSourceFactory Cleared and passivated DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712'

on the second load I see this, for the same dataSources:

DEBUG PoolableDataSourceFactory Activated DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712'
DEBUG PoolableDataSourceFactory Cleared and passivated DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712'

does this seem correct?

About the java profiler, unfortunately I'm not an expert, at a first glance it seems that a lot of time is spent in that _cloneConfigForSecurityAnnotations method, does this even make sense?

[Isomorphic]

Pooling is on by default, with certain exceptions (like DynamicDSGenerator). As we mentioned, if you temporarily turn on pooling-related logs, you will see log messages about DataSources being borrowed and returned. Background here:

https://smartclient.com/smartclient-...Implementation

If you confirm that pooling has not been disabled, we would recommend using a Java profiler to see where the bottlenecks are. It's probably going to be something weird that no one could have guessed would be the culprit in advance.