[
https://issues.apache.org/jira/browse/DERBY-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-3791:
-----------------------------------
Derby Info: [Regression] (was: [Regression, Patch Available])
That is about right.
Of course there is an exception, and I'm not sure how to handle it yet.
When a Clob is created with Connection.createClob and grows big enough, or a
Clob is fetched from the database and then modified, data is copied to a
temporary file on disk.
If you then read from this Clob again, you get a stack that looks something
like this (seen from Clob.getCharacterStream):
ClobUpdatableReader
UTF8Reader
LOBInputStream
LOBStreamControl
LOBFile
(Storage)RandomAccessFile
As far as I can see, this stack will be unbuffered (in our Java code, don't
know how the OS can help here) after patch 1a is applied.
The code is getting pretty complex down in LOBStreamControl and LOBFile, so I
think patch 1a has to be reworked to account for the buffering in a sensible
way higher up in the stack - probably in UTF8Reader.
I didn't see any performance degradation in suites.All with the patch, but that
probably just means we don't test this code path very well. I'll see if I can
write a series of tests and maybe put them under
java/testing/org/apache/derbyTesting/perf/basic/jdbc/.
I'm clearing the patch available flag, patch 1a will not be committed.
> Excessive memory usage when fetching small Clobs
> ------------------------------------------------
>
> Key: DERBY-3791
> URL: https://issues.apache.org/jira/browse/DERBY-3791
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.2.2.0, 10.3.1.4, 10.4.1.3, 10.5.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Attachments: derby-3791-1a-buffer_fix.diff
>
>
> When investigating DERBY-3312 I found out that performance with the embedded
> driver has decreased a lot as well.
> Analysis on trunk indicate excessive memory usage, causing high allocation
> and garbage collection costs.
> I believe there was another major performance problem in 10.3, but it appears
> fixed in trunk. I have not spent time identifying this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
