« Return to Thread: Velocity, ByteBuffers and GatheringByteChannels

Re: Velocity, ByteBuffers and GatheringByteChannels

by Byron Foster-2 :: Rate this Message:

On Apr 22, 2009, at 0:52 , Babak Farhang wrote:

>> I'm not sure why you need to hack Velocity for this. You can
>> create your
>> own Writer that is wired up to do whatever you need, for example
>> write to a
>> ByteBuffer. Then pass your custom Writer to the merge. Is there any
>> functionality that this approach wouldn't accommodate?
>
> That approach is certainly "functional", but it's not as efficient as
> the approach I'm describing. The approach I have in mind does away
> with the extra copying of the static parts of the output.
>
> In Velocity, the static parts of the output, if I understand right,
> are internally represented at runtime as char arrays (in ASTText), no?
> I'm suggesting if we managed to create a ByteBuffer representation
> along-side that char array (e.g. UTF-8 encoded), then we could
> "collect" these ByteBuffers by just returning a new (read-only) view
> of them. I'm thinking since most of the generated content is in fact
> made up of static parts, the memory savings might be significant.

In the interest of performance you may make some gains since the
conversion of Char to some specified output encoding would not be
necessary. My guess is that in practice the gains would be minimal,
but it would be interesting to test.

In the interest of memory it depends on what you would consider
significant. As it stands there are actually two copies of the static
text stored, one within the Char array as you mention above, and a
String object that is created as an artifact of the parser (look at
ASTText.init method). A byte array that contains the UTF-8 encoding
would be about half the size of the existing Char array. The very
best you could do with a very simple template is reduce the total
memory size by 25%. With a more complex template that contains many
AST nodes your results will not be as good.

In practice you would loose the flexibility of a Template being output
encoding neutral, but in practice there is usually only one output
encoding anyway. I'm dubious about the gains, but it would be
interesting to explore.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@...
For additional commands, e-mail: user-help@...

« Return to Thread: Velocity, ByteBuffers and GatheringByteChannels