A
Arved said:
Object/Relational mapping = ORM
We are very close to the point for many problems when you can store
your entire database in RAM or Flash RAM. It would seem to me, that
should spawn a new set of tools for managing data that don't have to
worry about fine tuning access times.
I also think there should be a database that deals with Java objects,
I added the missing "not" you clearly meant to have in there ;-)
What he says is certainly good, but I am not sure
that it is all new.
Using an ORM does [not] make all problem disappear. But that
is just a special case of: using tool X does not make
all problem disappear. But making some problems
disappear is still good.
Arne
What he says is certainly good, but I am not sure
that it is all new.
Using an ORM does [not] make all problem disappear. But that
is just a special case of: using tool X does not make
all problem disappear. But making some problems
disappear is still good.
I added the missing "not" you clearly meant to have in there ;-)
Roedy said:Object/Relational mapping = ORM
We are very close to the point for many problems when you can store
your entire database in RAM or Flash RAM. It would seem to me, that
should spawn a new set of tools for managing data that don't have to
worry about fine tuning access times.
I also think there should be a database that deals with Java objects,
that lets you iterate using ordinary java for : each loops. If the
whole thing were designed with a Java API in mind, surely it should be
able to do more that SQL with much less futzing.
Jan said:Overall implementation size of the indexer:
- 9 Classes
I also went for a custom implementation of some of
the Collection classes, to have the algorithms not
use iterators, but inline loops for speed. Isn't
possible with the existing classes since one cannot
access the fields.
David said:Isn't that the sort of optimization a JIT compiler
is supposed to be able to do?
This would be a very very good JIT compiler. Since the
issues is not simply inlining setters/getters.
The issue is that there are at first hand no setter/getters.
For example the table field of a HashMap is private.
And then an iterator implies creating a new stateful object. ....
When doing the above iteration with an iterator, the iterator
must keep i and e as a state, typically on the heap. Without
an iterator i and e can be registers.
David said:Many moons ago I was peripherally involved in a project that was
producing highly optimizing compilers for conventional programming
languages. I seem to recall some discussion of being able to eliminate
some heap allocations via dependency analysis, where one could sometimes
detect that the heap object lifetime didn't extend beyond the invocation
of the procedure that allocated it. Is this not possible with Java/JIT?
Jan said:But if you know that youre deployment range will be only
top-notch JITs you might go into the pain of adding additional
class to the package for the iterator implementations. This
would blow up the packgage to 11 classes, counting the
.class files.
For example I am developing the same code base for later
use in both Swing and Android. And the Dalvik JIT for
Android is lacking a little bit behind, you can even read
recommendations to not use setters/getters (sic!) if possible
markspace said:Just curious: I've never done an Android development. How does one
profile code for that environment? Do you have a Dalvik JVM that runs
on Windows/Unix (i.e. an emulator of some sort)? Is there a good
profiling tool that can attach to certain Android devices?
I guess there are some tools around. Android has its own
way of instrumentation for tracing.
http://developer.android.com/guide/developing/debugging/debugging-tracing.html
Jan said:Yes some JITs can do the required escape analysis to some
extent. But when talking about JITs there is always a weak
JIT and a strong JIT, since there are different providers on
the market.
For example I am developing the same code base for later
use in both Swing and Android. And the Dalvik JIT for
Android is lacking a little bit behind, you can even read
recommendations to not use setters/getters (sic!) if possible
in code written for Dalvik.
So I am helping the JIT and I am helping the application.
The code fragment under discussion is heavily used internally
to the API, since the indexing is dynamic. It is still possible
for the dynamic multi-indexing API, the package which has 9 classes,
to provide a proper Iterator interface to the outside, and use
this by the application.
But if you know that youre deployment range will be only
top-notch JITs you might go into the pain of adding additional
class to the package for the iterator implementations. This
would blow up the packgage to 11 classes, counting the
.class files.
markspace said:Good link, thanks for posting that.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.