Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 2.0.8
    • Component/s: Core
    • Labels:
      None

      Description

      I'd like to see IoBuffer enhanced to support prepending data. It could work as follows:

      • A means to specificy or reserve space should be provided. An IoBuffer.reserve() method could do the trick, and maybe a 3-parameter version of IoBuffer. IoBuffer.reserve() would keep the position at zero, but decrease the capacity and limit by the given number of bytes, and move the buffer start up by the given number of bytes.
      • A means to reclaim the space must be provided. An IoBuffer.reclaim() would work by moving the buffer start back down by the given amount, maybe returning a slice to the recovered area. Or another alternative would be to have a series of prepend* methods which would prepend bytes/ints/etc. similar to put*(), but rather than adding to the end of the buffer, they would add to the beginning, moving the buffer start back down to the start of the just-written data. Though I'm not sure how helpful it would be to add another dozen methods to a class that already has probably over a hundred methods.
      • Care should be taken that the mechanism to prepend data does not allow a user to "escape" a buffer slice.

        Activity

        Hide
        elecharny Emmanuel Lecharny added a comment -

        Utterly complicated proposal. At some point, one should rely on the GC to handle the fast allocation of buffer, instead of manipulating existing buffers, that will need to be somehow cached, leading to management costs and synchronization issue. "Better" is the enemy of "good enough".

        Unless someone comes with a proven faster and more efficient solution...

        Show
        elecharny Emmanuel Lecharny added a comment - Utterly complicated proposal. At some point, one should rely on the GC to handle the fast allocation of buffer, instead of manipulating existing buffers, that will need to be somehow cached, leading to management costs and synchronization issue. "Better" is the enemy of "good enough". Unless someone comes with a proven faster and more efficient solution...
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Will be rethink totally in 3.0.

        Show
        elecharny Emmanuel Lecharny added a comment - Will be rethink totally in 3.0.
        Hide
        trustin Trustin Lee added a comment -

        hmmm I think we need to try to implement a cool Composite buffer first to see how much capability it can have. Then we could decide we need prepend operations. Let me speed up!

        Show
        trustin Trustin Lee added a comment - hmmm I think we need to try to implement a cool Composite buffer first to see how much capability it can have. Then we could decide we need prepend operations. Let me speed up!
        Hide
        dmlloyd David M. Lloyd added a comment -

        Yes, this might be possible. However, the semantics of a composite IoBuffer might be necessarily limited - in other words, writing might have to be disallowed to make it work predictably, or to make the implementation practical. Also if you compare the complexity of using a composite IoBuffer versus the current technique that I use, which is just to .skip() a set amount of bytes (and of course remember to .skip() the same number of bytes on .flip()), it may not be worth it.

        In conclusion: ?????

        Show
        dmlloyd David M. Lloyd added a comment - Yes, this might be possible. However, the semantics of a composite IoBuffer might be necessarily limited - in other words, writing might have to be disallowed to make it work predictably, or to make the implementation practical. Also if you compare the complexity of using a composite IoBuffer versus the current technique that I use, which is just to .skip() a set amount of bytes (and of course remember to .skip() the same number of bytes on .flip()), it may not be worth it. In conclusion: ?????
        Hide
        trustin Trustin Lee added a comment -

        Oh I see. Then it sounds pretty complicated comparing to CompositeIoBuffer idea. What do you think about waiting for CompositeIoBuffer implementation? You could allocate another buffer and create a new CompositeIoBuffer with the two buffers.

        Show
        trustin Trustin Lee added a comment - Oh I see. Then it sounds pretty complicated comparing to CompositeIoBuffer idea. What do you think about waiting for CompositeIoBuffer implementation? You could allocate another buffer and create a new CompositeIoBuffer with the two buffers.
        Hide
        dmlloyd David M. Lloyd added a comment -

        Only if you copy the data - I'm proposing that a mechanism be added to reserve space at the start of the buffer. This way you could prepend data without incurring the overhead of copying.

        Show
        dmlloyd David M. Lloyd added a comment - Only if you copy the data - I'm proposing that a mechanism be added to reserve space at the start of the buffer. This way you could prepend data without incurring the overhead of copying.
        Hide
        trustin Trustin Lee added a comment - - edited

        Doesn't prepending slow down the overall performance degradation unless we have a CompositeIoBuffer?

        We could simply provide move() method to create some room for prepending. WDYT?

        Show
        trustin Trustin Lee added a comment - - edited Doesn't prepending slow down the overall performance degradation unless we have a CompositeIoBuffer? We could simply provide move() method to create some room for prepending. WDYT?
        Hide
        dmlloyd David M. Lloyd added a comment -

        Or, to avoid extra methods, you could use a negative index for put*(int index, ...). Though that might introduce bugs since it's a behavior change...

        Show
        dmlloyd David M. Lloyd added a comment - Or, to avoid extra methods, you could use a negative index for put*(int index, ...). Though that might introduce bugs since it's a behavior change...
        Hide
        dmlloyd David M. Lloyd added a comment -

        I guess the "prepend*()" methods would be more efficient overall than returning a slice, since a slice would always incur the overhead of, well, creating a slice, even if all you're doing is writing a single byte or int.

        Show
        dmlloyd David M. Lloyd added a comment - I guess the "prepend*()" methods would be more efficient overall than returning a slice, since a slice would always incur the overhead of, well, creating a slice, even if all you're doing is writing a single byte or int.

          People

          • Assignee:
            Unassigned
            Reporter:
            dmlloyd David M. Lloyd
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development