db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5947) Factor out common code from generated classes
Date Tue, 16 Oct 2012 11:53:03 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Knut Anders Hatlen updated DERBY-5947:
--------------------------------------

    Attachment: values1-after-2a.txt
                d5947-2a-execute-method.diff

Attaching d5947-2a-execute-method.diff, which builds on top of the 1a
patch by factoring out some common code from the execute() methods of
the generated classes.

It also does a little massaging of the code that's still generated for
the execute() method to make it more compact.

The 2a patch reduces the size of each generated class by 91 bytes, or
230 bytes in total when counting the additional reduction we get from
the 1a patch.

The file values1-after-2a.txt shows what a generated class for a
VALUES 1 statement looks like when the patch is applied.

Before the patch, there would be an execute() method like this one:

{code}
    public ResultSet execute() throws StandardException {
	this.throwIfClosed("execute");
	this.startExecution();
	ResultSet resultset;
	if (resultSet == null) {
	    ResultSet resultset_3_ = fillResultSet();
	    ace50d80a4x013ax6409x6343x000003196d400 var_ace50d80a4x013ax6409x6343x000003196d400_4_
		= this;
	    resultset
		= var_ace50d80a4x013ax6409x6343x000003196d400_4_.resultSet
		= resultset_3_;
	} else
	    resultset = resultSet;
	((NoPutResultSet) resultset).markAsTopResultSet();
	return resultset;
    }
{code}

After the patch, there is a shorter doExecute() method instead of the
original execute() method:

{code}
    protected ResultSet doExecute() throws StandardException {
	ResultSet resultset = resultSet;
	if (resultset == null) {
	    ace50d80a4x013ax64d6xddb7x00000319bb880 var_ace50d80a4x013ax64d6xddb7x00000319bb880_3_
		= this;
	    resultset
		= var_ace50d80a4x013ax64d6xddb7x00000319bb880_3_.resultSet
		= var_ace50d80a4x013ax64d6xddb7x00000319bb880_3_
		      .fillResultSet();
	}
	((NoPutResultSet) resultset).markAsTopResultSet();
	return resultset;
    }
{code}

The first two calls have been taken out of the generated method and
have been moved to a shared execute() method in the super class. The
shared method calls the generated doExecute() method.

Additionally, the code in the generated method has been massaged so
that it only looks up the value of the resultSet field once. That is,
there is no longer an else branch that does a second look-up.

All the regression tests ran cleanly with the patch. (Ran the full
suite on JDK 7, and also the lang suite on OJEC to verify that the new
layout of the generated classes didn't cause any class format problems
on the small platforms.)

Patch details:

BaseActivation:

- Added new abstract method, doExecute(), to be implemented by the
  generated classes.

- Added implementation of Activation.execute() which contained the
  code that was previously added to every generated class. Finally, it
  calls the abstract doExecute() method to allow the generated classes
  to add logic to it.

- Moved the body of the startExecution() method into execute() and
  removed it, since it's so small and there are no other callers of it
  after the changes in this patch.

ConstantActionActivation:

- Renamed the execute() method to doExecute() and removed the code
  that's identical to the code that now lives in BaseActivation's
  execute() method.

ActivationClassBuilder:

- Renamed the generated execute() method to doExecute().

- Removed the code that generated the logic that now lives in
  BaseActivation.execute().

StatementNode:

- Updated the generated code to keep the value of the resultSet field
  on the stack to avoid a second look-up when it's non-null.

- Updated the generated code to push the instance for the getField()
  operation earlier to avoid the need to swap operands.
                
> 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,
natural-join-decompiled.txt, values1-after-1a.txt, values1-after-2a.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

Mime
View raw message