You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <ji...@apache.org> on 2007/10/30 04:21:51 UTC
[jira] Updated: (DERBY-739) Reduce generated code required to
access a parameter's value
[ https://issues.apache.org/jira/browse/DERBY-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-739:
---------------------------------
Affects Version/s: 10.1.3.2
> Reduce generated code required to access a parameter's value
> ------------------------------------------------------------
>
> Key: DERBY-739
> URL: https://issues.apache.org/jira/browse/DERBY-739
> Project: Derby
> Issue Type: Sub-task
> Components: Services
> Affects Versions: 10.1.3.2
> Reporter: Daniel John Debrunner
> Assignee: Kathey Marsden
> Priority: Minor
> Fix For: 10.2.1.6
>
> Attachments: derby739_2.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.
-
You can reply to this email to add a comment to the issue online.