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 "Kristian Waagan (JIRA)" <ji...@apache.org> on 2008/12/03 10:19:44 UTC

[jira] Closed: (DERBY-3825) StoreStreamClob.getReader(charPos) performs poorly

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

Kristian Waagan closed DERBY-3825.
----------------------------------


Closing the issue.

Note that getReader is still rather low-performant, compared to what it could have been. Again the cause is positioning. The trick I used for getInternalReader cannot be used, because the reader from getReader is passed out to the user and cannot be shared.
Given the current requirements and limitations, a possible optimization is to remember one or more byte/char position and then be able to skip bytes instead of chars. The latter requires decoding, the former doesn't.

On the other side, if a user just obtains one reader and keeps reading from it, the initial positioning cost doesn't matter that much.
The problem with getSubString has been resolved by the patches committed.

> 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
>            Assignee: Kristian Waagan
>             Fix For: 10.4.2.1, 10.5.0.0
>
>         Attachments: derby-3825-0a-preview.diff, derby-3825-1a-reset_readpositioninbuffer.diff, derby-3825-2a-internalReader_repositioning.diff, derby-3825-2a-internalReader_repositioning.stat, derby-3825-2b-internalReader_repositioning.diff, derby-3825-3a-simplification.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.