Optimizing Java using D

[Dmitry Olshansky via Digitalmars-d]

05-Jul-2014 18:02, Wanderer пишет:
> On Friday, 4 July 2014 at 12:18:54 UTC, Daniel Murphy wrote:
>> Yes they do. http://en.wikipedia.org/wiki/Database_index#Clustered
>>
>> You can obviously only do that for one index.
>
> Ugh, and what happens in such hypothetical database if you update its
> first row so it becomes 1 byte longer than before?

Provision some extra space in each record. DBs do this all the time, 
regardless of layout.

> Total reordering of
> the whole database just to maintain that index? That's very similar to
> the issue I posted above - wasteful shuffling of big amounts of memory
> only because D's structs don't support indirection by their nature, and
> you can't swap two elements without copying their whole contents.

It's funny to see how an _ability_ to avoid indirection can be framed as 
a problem. Nothing prevents having an array of pointers to structs or 
just using classes if desired.

On the contrary sorting an array of pairs of integers in say Java is 
shamefully inefficient. No wonder packed objects (=value types)  are 
coming to Java, to address these sorts of need.

http://www.slideshare.net/mmitran/ibm-java-packed-objects-mmit-20121120

> John Colvin said above that structs can be useful, even together with
> sorting (and similar algorithms), if they are relatively small. This is
> true, but this design is not scalable. As soon as your program evolves
> and your struct grows with more and more fields, D's sort on it becomes
> slower and slower, proportionally to the struct's size. That's not the
> best behavior IMHO.

Ehm. One can always redesign struct layout to push stuff out through an 
indirection. And it's not like structs grow organically on their own ;)

In the same vane design of ref-to-instance is not scalable with millions 
of items scattered across the memory causing awful cache miss rate (as 
the indirection got to be crossed to compare things), not to mention the 
memory wasted per each object.

-- 
Dmitry Olshansky