On May 22, 2009, at 10:35 AM, Alex Esterkin wrote:
> I did not notice much data copying when stepping through the code in
> the debugger...
Blobs/strings are the issue. This is also very engine dependent.
> The problem with Value class is that it forces early data
> materialization and imposes dataflow patterns and paradigms in many
> additional places and situations. This will surely slow down
> complex function evaluation, among other things.
This was Jim Starkey's idea and it was based on his conclusions with
issues he was have with Falcon being required to materialize/copy data
I happen to agree with the design for the most part. It would not be
optimal for Heap/MyISAM, but for quite a few of the engines I have
seen I think it would work out better.
You can control the materialization based on access to the object. The
big issues around doing this work would be around how modify MyISAM/
Heap. Straightforward? Maybe?
But it is a lot of work.
> Alex Esterkin
> On Fri, May 22, 2009 at 12:37 PM, Brian Aker <brian@stripped>
>> On May 22, 2009, at 8:51 AM, Alex Esterkin wrote:
>>> objects make very little sense to me. I am not sure I understand
>>> intended purpose and benefit of this development task and of Value
>> The theory is that there is a lot of copying going on in the
>> server and
>> that a value object might solve some of this. It would also keep
>> for a nice
>> bit of abstraction around data held by engines.
>> The current system is very optimized for MyISAM/HEAP, and there
>> may, or may
>> not, be some gain in removing that to make the interface more
>> optimum for
>> other engines. See the earlier thread about the contents of row
>> and the
>> unireg in memory format.
>> Keep in mind that in all of the current trees MyISAM/HEAP are used as
>> internal temp tables and that any change could easily result in poor
>> performance in the core.
Brian "Krow" Aker, brian at tangent.org
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
You can't grep a dead tree.