[
https://issues.apache.org/jira/browse/TORQUE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840117#comment-17840117
]
Georg Kallidis commented on TORQUE-364:
---------------------------------------
I integrated the snippet, please check the code and message, thanks!
MappingStrategy is enabled ny default. This could be changed by an enable flag
in options.properties in torque-generate (useMappingStrategy) and is by default
enabled and a sorting flag (as well enabled by default). It is used in the
template recordMapperBase.vm. Sorting might be some performance issue for table
with a lot columns.
I tried to keep the code as much as it was, just inlining the new strategy
keeping the logic and still using the HashSet. Nevertheless each call of
processRow requires a new MappingStrategy object instance.
> RecordMapper very slow on many columns in table
> -----------------------------------------------
>
> Key: TORQUE-364
> URL: https://issues.apache.org/jira/browse/TORQUE-364
> Project: Torque
> Issue Type: Improvement
> Components: Runtime, Templates
> Affects Versions: 5.1
> Reporter: Max Philipp Wriedt
> Priority: Major
> Labels: criteria_api, om, performance, recordmapper, templates
>
> When "doSelect()" a large quantity of columns in a table the default
> RecordMappers generated by Om-Templates (processRow()) cause an
> !https://wikimedia.org/api/rest_v1/media/math/render/svg/4441d9689c0e6b2c47994e2f587ac5378faeefba!
> Problem. (technically O(rows * columns))
> Specifically, constantly generating the SQL expression of all possible
> columns for every row in the result causes excessive use of StringBuilders
> which slow the mapping process to a crawl.
> I currently have two ideas on how best to tackle this problem:
> # Either generate all SQL column expressions once when a (template
> generated) RecordMapper is first created (using final static String fields)
> thus reducing the cost for every row to generating all selected column SQL
> expressions once(instead of every selected column times every available
> column)
> # Or (in case the first approach generates unacceptably excessive number of
> fields for RecordMappers) adjust the RecordMapper API to allow a
> "prepare(Criteria, int offset)" method to be called once before processing
> any rows and implement it on generated RecordMappers to scan the Criteria and
> build two lists: One containing references to the setXXX methods of the
> mapper in the order they appear in the ResultSet (via the order in the
> Criteria) and a second list containing the corresponding column offsets. This
> would allow the processRow method to only iterated over both lists
> simultaneously and call the referenced methods with the result set and offset
> immediately. (Alternatively one list using lambdas could be used but I am
> currently not sure about the stance or impact of these lambdas in the Torque
> project.)
> credits to [~refarb]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
