[ http://issues.apache.org/jira/browse/DERBY-739?page=all ]
Kathey Marsden updated DERBY-739:
---------------------------------
Attachment: derby739.diff
As per the description of this bug , this patch adds a getParameter() method
to BaseActivation so that code can be generated as
this.getParameter(position) instead of this.pvs.getParameter(postition).
For an IN predicate the maximum number of parameters increased from 2700 to
3400.
I'll commit this tomorrow if noone sees issues.
> Reduce generated code required to access a parameter's value
> ------------------------------------------------------------
>
> Key: DERBY-739
> URL: http://issues.apache.org/jira/browse/DERBY-739
> Project: Derby
> Type: Sub-task
> Reporter: Daniel John Debrunner
> Assignee: Kathey Marsden
> Priority: Minor
> Attachments: derby739.diff
>
> When accessing a parameter the generated code is:
> this.pvs.getParameter(23);
> A slightly shorter form would be
> this.getParameter(23);
> if a getParameter() method was added to BaseActivation that simply did:
> protected final DataValueDescriptor getParameter(int n) { return
> pvs.getParameter(n); }
> ------------------------------
> An interesting separate idea, to reduce the number of constant pool entries
> would be to have multiple getParameter() methods, that took values from 0-5
> to construct the actual parameter number.
> getParameter(3) -- > 3 parameter (0 based)
> getParameter(2, 1) --> 13 parameter (2*6 + 1)
> getParameter(5, 1, 4) --> 190 parameter (5*36 + 1*6+ 4)
> above the limit of three args, revert to getParameter(n)
> This should probably be a separate issue and probably would increease code
> size which would not help DERBY-732 , it's a tradeoff between constant pool
> entries and code size.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
