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 "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2006/11/28 19:54:24 UTC
[jira] Created: (DERBY-2122) Optimize ContainerLock.isCompatible()
Optimize ContainerLock.isCompatible()
-------------------------------------
Key: DERBY-2122
URL: http://issues.apache.org/jira/browse/DERBY-2122
Project: Derby
Issue Type: Improvement
Components: Store
Affects Versions: 10.2.1.6
Reporter: Knut Anders Hatlen
Assigned To: Knut Anders Hatlen
Priority: Trivial
The numbers at http://wiki.apache.org/db-derby/Derby1961MethodCalls indicate that ContainerLock.isCompatible() is called many times per transaction, at least when there are multiple concurrent clients operating on the same containers. Currently, it looks into a two-dimensional array to find out whether two locks are compatible. This could be implemented more efficiently, for instance by having a bit pattern in each ContainerLock object representing which lock types it is compatible with.
--
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
[jira] Closed: (DERBY-2122) Optimize ContainerLock.isCompatible()
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-2122?page=all ]
Knut Anders Hatlen closed DERBY-2122.
-------------------------------------
Fix Version/s: 10.3.0.0
Resolution: Fixed
Derby Info: (was: [Patch Available])
Committed v2 patch with revision 481181.
> Optimize ContainerLock.isCompatible()
> -------------------------------------
>
> Key: DERBY-2122
> URL: http://issues.apache.org/jira/browse/DERBY-2122
> Project: Derby
> Issue Type: Improvement
> Components: Store, Performance
> Affects Versions: 10.2.1.6
> Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
> Priority: Trivial
> Fix For: 10.3.0.0
>
> Attachments: derby-2122-v1.diff, derby-2122-v1.stat, derby-2122-v2.diff, derby-2122-v2.stat
>
>
> The numbers at http://wiki.apache.org/db-derby/Derby1961MethodCalls indicate that ContainerLock.isCompatible() is called many times per transaction, at least when there are multiple concurrent clients operating on the same containers. Currently, it looks into a two-dimensional array to find out whether two locks are compatible. This could be implemented more efficiently, for instance by having a bit pattern in each ContainerLock object representing which lock types it is compatible with.
--
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
[jira] Commented: (DERBY-2122) Optimize
ContainerLock.isCompatible()
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-2122?page=comments#action_12454117 ]
Knut Anders Hatlen commented on DERBY-2122:
-------------------------------------------
Thanks Mike, that's a good point. Perhaps it would be even better if we left the 2-d arrays and built the bit masks from them at initialization time.
> Optimize ContainerLock.isCompatible()
> -------------------------------------
>
> Key: DERBY-2122
> URL: http://issues.apache.org/jira/browse/DERBY-2122
> Project: Derby
> Issue Type: Improvement
> Components: Store, Performance
> Affects Versions: 10.2.1.6
> Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
> Priority: Trivial
> Attachments: derby-2122-v1.diff, derby-2122-v1.stat
>
>
> The numbers at http://wiki.apache.org/db-derby/Derby1961MethodCalls indicate that ContainerLock.isCompatible() is called many times per transaction, at least when there are multiple concurrent clients operating on the same containers. Currently, it looks into a two-dimensional array to find out whether two locks are compatible. This could be implemented more efficiently, for instance by having a bit pattern in each ContainerLock object representing which lock types it is compatible with.
--
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
[jira] Updated: (DERBY-2122) Optimize ContainerLock.isCompatible()
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-2122?page=all ]
Mike Matrigali updated DERBY-2122:
----------------------------------
I think you should add back some sort of compatibility "table" documentation. It may just be me but I often refer to this
source code to figure out what locks are compatible with what. Since the previous implementation had it as a 2-d array
with true/false I didn't need extra comments. But I find it harder to read the code encoding into bit maps. I wouldn't hold
up a commit for this.
I hand checked all the compatibility conversions and they all looked right.
> Optimize ContainerLock.isCompatible()
> -------------------------------------
>
> Key: DERBY-2122
> URL: http://issues.apache.org/jira/browse/DERBY-2122
> Project: Derby
> Issue Type: Improvement
> Components: Store, Performance
> Affects Versions: 10.2.1.6
> Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
> Priority: Trivial
> Attachments: derby-2122-v1.diff, derby-2122-v1.stat
>
>
> The numbers at http://wiki.apache.org/db-derby/Derby1961MethodCalls indicate that ContainerLock.isCompatible() is called many times per transaction, at least when there are multiple concurrent clients operating on the same containers. Currently, it looks into a two-dimensional array to find out whether two locks are compatible. This could be implemented more efficiently, for instance by having a bit pattern in each ContainerLock object representing which lock types it is compatible with.
--
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
[jira] Updated: (DERBY-2122) Optimize ContainerLock.isCompatible()
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-2122?page=all ]
Knut Anders Hatlen updated DERBY-2122:
--------------------------------------
Attachment: derby-2122-v1.diff
derby-2122-v1.stat
The attached patch removes the compatibility matrix from ContainerLock and instead maintains a bit mask containing the type ids of the compatible lock types. Compatibility checking between two lock types could therefore be performed by a bitwise and of the the bit mask and the type id.
Similar changes were made to RowLock to keep the two classes consistent.
I have run some experiments with this patch and the test client from DERBY-1961 (single-record selects with 16 concurrent clients on embedded Derby).
Experiment 1: 40 runs (20 with clean trunk, 20 with patch for ContainerLock only) consisting of 30 seconds warm-up and 60 seconds counting transactions. Result: Average throughput increased by 1.2% with the patch.
Experiment 2: Same as above, but counting transactions for 100 seconds instead of 60 seconds. Result: Average throughput increased by 1.7% with the patch.
Experiment 3: Same as above, but with the full patch (that is, both ContainerLock and RowLock changed). Result: Average throughput increased by 1.9% with the patch.
I don't have a fancy script that calculates how significant these numbers are (can do it on request, since I really need to refresh my statistics skills), but they at least give an indication that the patch has a small positive impact.
Reviews would be appreciated. Thanks.
> Optimize ContainerLock.isCompatible()
> -------------------------------------
>
> Key: DERBY-2122
> URL: http://issues.apache.org/jira/browse/DERBY-2122
> Project: Derby
> Issue Type: Improvement
> Components: Store, Performance
> Affects Versions: 10.2.1.6
> Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
> Priority: Trivial
> Attachments: derby-2122-v1.diff, derby-2122-v1.stat
>
>
> The numbers at http://wiki.apache.org/db-derby/Derby1961MethodCalls indicate that ContainerLock.isCompatible() is called many times per transaction, at least when there are multiple concurrent clients operating on the same containers. Currently, it looks into a two-dimensional array to find out whether two locks are compatible. This could be implemented more efficiently, for instance by having a bit pattern in each ContainerLock object representing which lock types it is compatible with.
--
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
[jira] Updated: (DERBY-2122) Optimize ContainerLock.isCompatible()
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-2122?page=all ]
Knut Anders Hatlen updated DERBY-2122:
--------------------------------------
Component/s: Performance
> Optimize ContainerLock.isCompatible()
> -------------------------------------
>
> Key: DERBY-2122
> URL: http://issues.apache.org/jira/browse/DERBY-2122
> Project: Derby
> Issue Type: Improvement
> Components: Store, Performance
> Affects Versions: 10.2.1.6
> Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
> Priority: Trivial
>
> The numbers at http://wiki.apache.org/db-derby/Derby1961MethodCalls indicate that ContainerLock.isCompatible() is called many times per transaction, at least when there are multiple concurrent clients operating on the same containers. Currently, it looks into a two-dimensional array to find out whether two locks are compatible. This could be implemented more efficiently, for instance by having a bit pattern in each ContainerLock object representing which lock types it is compatible with.
--
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
[jira] Updated: (DERBY-2122) Optimize ContainerLock.isCompatible()
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-2122?page=all ]
Knut Anders Hatlen updated DERBY-2122:
--------------------------------------
Attachment: derby-2122-v2.diff
derby-2122-v2.stat
New and simpler patch attached (v2). This patch keeps the compatibility arrays and builds bit masks from the arrays when the lock type objects are created. I had to move the definition of the compatibility arrays to make their values visible in the constructors (the constructors are called from static initializers, so the definition order of the static final variables matters).
Derbyall and the JUnit tests ran cleanly. Please review.
> Optimize ContainerLock.isCompatible()
> -------------------------------------
>
> Key: DERBY-2122
> URL: http://issues.apache.org/jira/browse/DERBY-2122
> Project: Derby
> Issue Type: Improvement
> Components: Store, Performance
> Affects Versions: 10.2.1.6
> Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
> Priority: Trivial
> Attachments: derby-2122-v1.diff, derby-2122-v1.stat, derby-2122-v2.diff, derby-2122-v2.stat
>
>
> The numbers at http://wiki.apache.org/db-derby/Derby1961MethodCalls indicate that ContainerLock.isCompatible() is called many times per transaction, at least when there are multiple concurrent clients operating on the same containers. Currently, it looks into a two-dimensional array to find out whether two locks are compatible. This could be implemented more efficiently, for instance by having a bit pattern in each ContainerLock object representing which lock types it is compatible with.
--
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
[jira] Updated: (DERBY-2122) Optimize ContainerLock.isCompatible()
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-2122?page=all ]
Knut Anders Hatlen updated DERBY-2122:
--------------------------------------
Derby Info: [Patch Available]
> Optimize ContainerLock.isCompatible()
> -------------------------------------
>
> Key: DERBY-2122
> URL: http://issues.apache.org/jira/browse/DERBY-2122
> Project: Derby
> Issue Type: Improvement
> Components: Store, Performance
> Affects Versions: 10.2.1.6
> Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
> Priority: Trivial
> Attachments: derby-2122-v1.diff, derby-2122-v1.stat
>
>
> The numbers at http://wiki.apache.org/db-derby/Derby1961MethodCalls indicate that ContainerLock.isCompatible() is called many times per transaction, at least when there are multiple concurrent clients operating on the same containers. Currently, it looks into a two-dimensional array to find out whether two locks are compatible. This could be implemented more efficiently, for instance by having a bit pattern in each ContainerLock object representing which lock types it is compatible with.
--
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
[jira] Updated: (DERBY-2122) Optimize ContainerLock.isCompatible()
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-2122:
---------------------------------
Derby Categories: [Performance]
> Optimize ContainerLock.isCompatible()
> -------------------------------------
>
> Key: DERBY-2122
> URL: https://issues.apache.org/jira/browse/DERBY-2122
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Affects Versions: 10.2.1.6
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Trivial
> Fix For: 10.3.1.4
>
> Attachments: derby-2122-v1.diff, derby-2122-v1.stat, derby-2122-v2.diff, derby-2122-v2.stat
>
>
> The numbers at http://wiki.apache.org/db-derby/Derby1961MethodCalls indicate that ContainerLock.isCompatible() is called many times per transaction, at least when there are multiple concurrent clients operating on the same containers. Currently, it looks into a two-dimensional array to find out whether two locks are compatible. This could be implemented more efficiently, for instance by having a bit pattern in each ContainerLock object representing which lock types it is compatible with.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2122) Optimize
ContainerLock.isCompatible()
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-2122?page=comments#action_12454087 ]
Knut Anders Hatlen commented on DERBY-2122:
-------------------------------------------
Oh, I forgot... Derbyall and the JUnit tests ran cleanly.
> Optimize ContainerLock.isCompatible()
> -------------------------------------
>
> Key: DERBY-2122
> URL: http://issues.apache.org/jira/browse/DERBY-2122
> Project: Derby
> Issue Type: Improvement
> Components: Store, Performance
> Affects Versions: 10.2.1.6
> Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
> Priority: Trivial
> Attachments: derby-2122-v1.diff, derby-2122-v1.stat
>
>
> The numbers at http://wiki.apache.org/db-derby/Derby1961MethodCalls indicate that ContainerLock.isCompatible() is called many times per transaction, at least when there are multiple concurrent clients operating on the same containers. Currently, it looks into a two-dimensional array to find out whether two locks are compatible. This could be implemented more efficiently, for instance by having a bit pattern in each ContainerLock object representing which lock types it is compatible with.
--
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