[
https://issues.apache.org/jira/browse/DERBY-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-5947:
--------------------------------------
Attachment: natural-join-after-3a.txt
values1-after-3a.txt
d5947-3a-init-rs.diff
Attaching d5947-3a-init-rs.diff, which moves the initialization of
BaseActivation's resultSet field from the generated code to
BaseActivation.execute().
The only logic that's left in the generated doExecute() method is code
that reinitializes the generated data-structures before each
execution. Because of this, I renamed the doExecute() method to
reinit().
BaseActivation is given an empty reinit() method so that those
generated classes that don't need to do any extra reinitialization,
don't need to lay out code for an empty method.
Also, since BaseActivation.execute() now needs to call the generated
method that creates the result set tree, an abstract method called
createResultSet() has been added to BaseActivation. This method is
implemented by all generated classes. It's the same method as the
previously private fillResultSet() method, only that it has been
renamed and made visible from BaseActivation.
With these changes, the amount of code generated for a VALUES 1
statement is reduced by yet another 234 bytes (total reduction: 464
bytes). A VALUES 1 statement doesn't have to generate a reinit()
method and benefits from the empty default method in BaseActivation. A
statement that generates a reinit() method, like the join whose
generated code I've attached before, the reduction will be a little
smaller; 188 bytes (total: 418 bytes).
As before, I'm attaching values1-after-3a.txt to show what the
generated class for a VALUES 1 statement looks like now. I'm also
attaching natural-join-after-3a.txt to show what the new reinit()
method looks like.
All the regression tests ran cleanly with the patch.
Patch details:
ActivationClassBuilder:
- Removed generation of code that now lives in BaseActivation.execute().
- In finishExecuteMethod(): Only complete the method if code has been
added to it (some simple statements don't add code to it anymore),
so that we don't have to generate an empty method.
- In getCurrentSetup(): Use getter method instead of accessing the
method builder directly, since the method builder is generated
lazily now and the field could therefore be null.
ExpressionClassBuilder:
- Generate the reinit() method lazily to prevent generation of the
method if no code is added to it.
StatementNode:
- Removed generation of code that now lives in BaseActivation.execute().
- Changed name and visibility for the fillResultSet() method so that
it matches the abstract method in BaseActivation.
BaseActivation:
- Added logic that used to be in the generated class. Note: In the
generated classes, markAsTopResultSet() used to be called on each
execution, but the new code only calls it once, when the result set
is created. Since markAsTopResultSet() just sets a flag to true, and
there is no code that ever changes it back to false, calling it once
per result set should be enough.
DMLModStatementNode:
DeleteNode:
InsertNode:
UpdateNode:
- Stop calling getExecuteMethod() unless the method builder is
actually going to be used. Otherwise, a reinit() method will be
created for all INSERT, UPDATE and DELETE statement, even if no code
is added to it and they could use the default implementation in
BaseActivation.
> Factor out common code from generated classes
> ---------------------------------------------
>
> Key: DERBY-5947
> URL: https://issues.apache.org/jira/browse/DERBY-5947
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: d5947-1a-remove-common-methods.diff,
> d5947-2a-execute-method.diff, d5947-3a-init-rs.diff,
> natural-join-after-3a.txt, natural-join-decompiled.txt, values1-after-1a.txt,
> values1-after-2a.txt, values1-after-3a.txt, values1-decompiled.txt
>
>
> There's some code that's added to all classes generated by Derby's query
> compiler. For example, there are three static fields that contain statistics
> used to check if the plan is stale, and there are getter and setter methods
> for each of the three fields. The fields and their accessor methods take up
> 468 bytes in every generated class.
> We should see if we can factor out some of this code so that there is a
> single shared copy in BaseActivation. Advantages would be: less complicated
> byte-code generation, less memory occupied by generated classes in the
> statement cache, smaller disk footprint for stored prepared statements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
