[ 
https://issues.apache.org/jira/browse/DERBY-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Waagan updated DERBY-3825:
-----------------------------------

    Attachment: derby-3825-0a-preview.diff

'derby-3825-0a-preview.diff' is a preview patch. It is incomplete and not for 
commit.

It introduces a new method for InternalClob: getInternalReader(charPos).
The idea is to keep only one such reader per clob that can be used internally - 
that is not published to the user. The most prominent example is 
Clob.getSubString().
There are two performance gains:
 1) Repositioning capabilities (see below).
 2) Less object creation (GC).

The repositioning functionality is added to UTF8Reader, and can be split into 
three types - ordered after increasing cost:
 a) Reposition within current character buffer (small hops forwards and 
potentially backwards - in range 1 char to 8K chars)
 b) Forward stream from current position (hops forwards)
 c) Reset stream and skip data (hops backwards)

The more I work with this, the more I feel the functionality should be pushed 
closer to store.

Preview patch ready for comments.

> StoreStreamClob.getReader(charPos) performs poorly
> --------------------------------------------------
>
>                 Key: DERBY-3825
>                 URL: https://issues.apache.org/jira/browse/DERBY-3825
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Store
>    Affects Versions: 10.5.0.0
>            Reporter: Kristian Waagan
>         Attachments: derby-3825-0a-preview.diff
>
>
> StoreStreamClob.getReader(charPos) performs poorly because it resets the 
> underlying stream and skips data until it reached the requested character 
> position. Not only does the data has to be skipped, it also has to be decoded 
> (UTF-8).
> The problem is exposed through EmbedClob.getSubString, which causes extremely 
> bad performance for the client driver because the locator based Clob 
> implementation uses this method.
> For the record, there is another read buffer size issue that exaggerates the 
> problem (it will probably be handled under DERBY-3769, and also DERBY-3818).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to