db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject [PATCH] Cleanup of special function nodes
Date Thu, 20 Jan 2005 19:21:38 GMT
Hash: SHA1

I'll apply this patch by next Monday if there are no objections.

This patch replaces two compile time query tree nodes
CurrentUserNode.java and CurrentIsolationNode.java with a single node

The driving force behind this is footprint, the Java class file format
imposes a penalty for multiple classes as String constants such as
method names, signatures and class names are repeated in each class.
E.g. if each class has a toString() method then each class will have the
constants 'java/lang/String', 'toString' etc. In addition the jar file
format has a per-class overhead. Thus moving common functionality into a
single class can reduce footprint.

In this case the classes CurrentUserNode (3801 bytes) and
CurrentIsolation (2757) are replaced with a single class
SpecialFunctionNode (4208).

The downside to moving functionality into single classes is that
typically more conditional code (if or switch statements) have to be
executed at runtime, and thus performance can degrade. Thus a decision
to consolidate should depend on the situation. The general rule of thumb
has been that additional conditional logic at SQL compile time is not an
issue, but is an issue at SQL execution time. Obviously in the case of
SQL execution time it depends on how frequently the piece of code is
likely to be executed by a typical application. Another consideration is
how much visual complexity is added by combining classes, if the code is
easier to understand in multiple classes then it should remain so.

I saw this opportunity to consolidate classes when chaging
IDENITY_VALUE_LOCAL to use Long instead of BigDecimal for the JSR 169
preperation work. That function was implemented in CurrentUserNode.java
which seemed misleading, and then I saw that node implemented other
non-user releated functions. Looking around in the other Nodes I saw a
pattern of special functions with near identical nodes. A blatent
example was CurrentIsolationNode where it was obviously copied from
CurrentUserNode as most of the comments still indicated CurrentUserNode.

Thus I created SpecialFunctionNode and made it have correct up to date
comments. It handles Special SQL functions which seem to have a pattern
of being implemented as a method call in LanguageConnectionContext,
though I believe other functions could be added here which are
implemented as method calls in Activation. Basically a SQL special
function returns state of the connection (session) or of the statement.

Other Nodes I think could be consolidated into SpecialFunctionNodes are:

GetCurrentConnectionNode - though this functionality should be removed,
it has been replaced by the standard jdbc:default:connection. There is
only one internal use of it at the moment.

CurrentDatetimeOperatorNode - a little more involved, as some setup
state manipulation has to be added.

Hope this the type of explaination that shahbaz chaudhary was looking for.


svn status outpur

M      java\engine\org\apache\derby\impl\sql\compile\NodeFactoryImpl.java
M      java\engine\org\apache\derby\impl\sql\compile\C_NodeNames.java
M      java\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj
M      java\engine\org\apache\derby\iapi\sql\compile\C_NodeTypes.java
D      java\engine\org\apache\derby\impl\sql\compile\CurrentUserNode.java

Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message