Good Fowler article on ORM

[Arved Sandstrom]

http://martinfowler.com/bliki/OrmHate.html

Given some of the threads we've had...

AHS
--
Never interrupt your enemy when he is making a mistake.
--Napoleon

[Lew]

Arved Sandstrom wrote:
> http://martinfowler.com/bliki/OrmHate.html
>
> Given some of the threads we've had...

Bookmarked.

This article succinctly explains points I've struggled to make over the years.
It gives an excellent description of the "impedance mismatch" between the
object and relational world views.

Now if all programmers who deal with object-to-relational mapping would
only read it.

Thanks for bringing it to our attention.

--
Lew

[Roedy Green]

On Thu, 10 May 2012 19:50:54 -0300, Arved Sandstrom
<asandstr...@eastlink.ca> wrote, quoted or indirectly quoted
someone who said :

>http://martinfowler.com/bliki/OrmHate.html
>
>Given some of the threads we've had...

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.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Programmers love to create simplified replacements for HTML.
They forget that the simplest language is the one you
already know. They also forget that their simple little
markup language will bit by bit become even more convoluted
and complicated than HTML because of the unplanned way it grows.
.

[Arne Vajhøj]

On 5/10/2012 6:50 PM, Arved Sandstrom wrote:
> http://martinfowler.com/bliki/OrmHate.html
>
> Given some of the threads we've had...

What he says is certainly good, but I am not sure
that it is all new. :-)

Using an ORM does 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

[Arne Vajhøj]

On 5/10/2012 7:52 PM, Roedy Green wrote:
> On Thu, 10 May 2012 19:50:54 -0300, Arved Sandstrom
> <asandstr...@eastlink.ca> wrote, quoted or indirectly quoted
> someone who said :
>> http://martinfowler.com/bliki/OrmHate.html
>>
>> Given some of the threads we've had...
>
> Object/Relational mapping = ORM

Well - everybody knows that.

> 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.

Persistence to disk is not just done because RAM is more expensive
than disk. People like to have their data after a power failure.

Flash RAM is disk not memory.

> I also think there should be a database that deals with Java objects,

It is called an OODBMS.

And if you had read the article you would know how they did not succeed.

Arne

[Daniel Pitts]

On 5/10/12 5:03 PM, Arne Vajhøj wrote:
> On 5/10/2012 6:50 PM, Arved Sandstrom wrote:
>> http://martinfowler.com/bliki/OrmHate.html
>>
>> Given some of the threads we've had...
>
> 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
>
>

I added the missing "not" you clearly meant to have in there ;-)

[Arne Vajhøj]

On 5/10/2012 9:40 PM, Daniel Pitts wrote:
> On 5/10/12 5:03 PM, Arne Vajhøj wrote:
>> On 5/10/2012 6:50 PM, Arved Sandstrom wrote:
>>> http://martinfowler.com/bliki/OrmHate.html
>>>
>>> Given some of the threads we've had...
>>
>> 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 ;-)

Thanks.

:-)

Arne

[markspace]

On 5/10/2012 3:50 PM, Arved Sandstrom wrote:
> http://martinfowler.com/bliki/OrmHate.html
>
> Given some of the threads we've had...

Good find, thanks for reposting the link here. It seems to give a
brief, pithy overview of ORM as it exists today.

I might say a bit more after I've had a chance to digest it more.

[Leif Roar Moldskred]

Roedy Green <see_w...@mindprod.com.invalid> wrote:

> 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.

Access time is rarely the bugbear you try to solve with a relational
database. Data integrity and management (in particular sharing and
canonicality), is.

--
Leif Roar Moldskred

[Jan Burse]

Roedy Green schrieb:

> On Thu, 10 May 2012 19:50:54 -0300, Arved Sandstrom
> <asandstr...@eastlink.ca> wrote, quoted or indirectly quoted
> someone who said :
>
>> http://martinfowler.com/bliki/OrmHate.html
>>
>> Given some of the threads we've had...
>
> 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.

You got the Collection classes in Java. You can
more or less map an SQL query on that if you have
your objects in the memory.

But what this doesn't buy you are indexes, respectively
automatic indexing as databases do nowadays. It is
very tediuous to manually have indexes and also doesn't
make your domain model easily extensible.

I have worked on a solution for an interpreted language
and came up with an automatic indexing scheme.
Initially it did only speed up the access. Recently
I have also worked out relative quick updates on the
data (*). Problem is a little bit to not throw away the
indexes too quickly. And having logical cursor like
access is also challenging.

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. Also the custom classes automatically
shrink the indexes, what the normal Collection classes
don't do.

Overall implementation size of the indexer:
- 9 Classes

I think indexes, or what has often been called access
paths, in one way or the other are always key to
databases. The problem carries over to memory
based solutions. But one can do with a library
of only a few classes for memory.

Bye

(*)
https://plus.google.com/u/0/b/103259555581227445618/103259555581227445618/posts/FtcxQBCudjU

[Jan Burse]

Jan Burse schrieb:

>
> Overall implementation size of the indexer:
> - 9 Classes

Maybe there are other, especially public, libraries
around. Didn't research yet, since I wasn't sure
about the specs until recently.

Bye

[David Lamb]

On 11/05/2012 4:06 AM, Jan Burse wrote:
> 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.

Isn't that the sort of optimization a JIT compiler is supposed to be
able to do?

[Jan Burse]

David Lamb schrieb:

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.
Take for example the following trivial iteration without
an iterator over a HashMap:

for (int i = 0; i<table.length; i++) {
Entry e = table[i];
while (e!=null) {
/* do something */
}
}

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.

Maybe some JITs are able to eliminate the heap allocation,
there is a further issues. The above loop does not do
modification checks. Which is valid in my application scenario.

So this is the second reason to inline the loops manually
for speed, less functionality is needed.

Of course one looses encapsulation of iterators. So it only
works a for a particular implementation of a HashMap, and
polymorphism is not anymore supported.

Bye

[David Lamb]

On 12/05/2012 6:01 AM, Jan Burse wrote:
> David Lamb schrieb:
>> On 11/05/2012 4:06 AM, Jan Burse wrote:
>>> 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.
>>
>> 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.

I confess to a high degree of ignorance about what current JIT compilers
are capable of, but I'd be surprised if inlining is all they can accomplish.

> The issue is that there are at first hand no setter/getters.
> For example the table field of a HashMap is private.

Hmm. Seems to me private/public status can't matter that much if a JIT
can inline setter/getters, since those typically access private data also.

> 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.

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 Burse]

David Lamb schrieb:

>
> 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?

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.

Bye

[Jan Burse]

Jan Burse schrieb:

>
> 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.

But I doubt this is necessary, since these classes will not
be seen by the client. The client only sees:

- Give me all tupples that match a given pattern

Inside the API this is then translated into:

- Oh the client wants tupples for a given pattern, lets
first find a suitable index.
- Alternative 1:
- Oh this part of the tupple already has a an index,
lets lookup this part of the tupple
- Pick the set found by the lookup
- Alternative 2:
- Oh this part of the tupple could profit from an index,
but there is none yet, lets build an index.
- Lookup this part of the tupple in the new index
- Pick the set found by the lookup
- Oh we have a set now, lets check whether the
set is already suitable.
- Alternative 1:
- The set is already small enough or there are
no more potential sub index.
- Return the set
- Alternative 2:
- The set is still large and there is a potential
sub index.
- Continue use case from start inside the set.

So the involved data structure is something along:

Index = ArrayList<HashMap<IndexAndTupples>>

But this is not visible to the client. The client
will only see:

Tupples = ArrayList<Tupple>

[markspace]

On 5/12/2012 4:14 AM, Jan Burse wrote:
>
> 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

Ah, good catch. I'd think that most JVMs intended for large servers
would easily do these sorts of optimizations, but I'd forgot about the
embedded market.

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?

[Jan Burse]

markspace schrieb:

> 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
Usually you can connect either to an emulator or to a
device connected via USB.

But I did not yet use it. Was just benchmarking my App and
saw that it runs much slower on Android. But that has also
to do with that I was using a tablet with something of 1GHz
ARM and was comparing against a 3.4GHz 64-bit Intel.

If you don't use a device but an emulator, you also observe
slowdown, since the Dalvik then runs inside the emulator (sic!).

(All the above just snapshot of 12.Mai 2012 and what I
currently have tried/know)

Bye

[markspace]

On 5/12/2012 9:21 AM, Jan Burse wrote:
> markspace schrieb:
>> 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
>

Good link, thanks for posting that.

[Lew]

Jan Burse wrote:
> 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.

True statements.

> 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.

"Setter" and "getter" are well-established informal terms with nothing
shameful in their pedigree.

One must be judicious in accepting such recommendations. I don't oppose direct
use of attribute values /per se/, but I do warn against microoptimization
early in the development cycle.

Write the code that most clearly expresses the model and behaviors it implements.

If you do use, say, 'public' variables in a class, strongly consider using
read-only values to immutable instances.

It is neither microoptimization nor premature to consider whether data will be
primarily read or frequently written. A good domain model considers the flow
and "shape" of information (size of data packets, frequency of transactions,
proportion of duplicates, etc.) and its transformation, not just the static
object model. Considerations of read-heaviness vs. write-happiness originate
in the domain model and are appropriate topics for early analysis. (Aside:
"write-happiness" was a typing accident that I shall let stand.) Whether an
attribute comes as a variable reference or a method call is an implementation
detail perhaps irrelevant to the domain model. An immutable final variable is
not dangerous and can be justified without fear that it's premature. It
directly expresses the intent, might (!) help on an Android and won't hurt
elsewhere.

OTOH I will continue to write my own Android code with getters and setters.

> So I am helping the JIT and I am helping the application.

And I'm sure the JIT is ever so grateful for your undoubtedly most useful
assistance.

You should back up such claims with hard evidence.

Measurable, repeatable tests.

I'm not saying you aren't helping, but "helping the optimizer" is so often
such an utterly outrageous claim that it can never be accepted on the face.

> 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.

I don't think I get your last paragraph here. What pain? What additional
classes? Why?

Regardless, source-code structure should nearly always express algorithm, not
platform. Deviations should stem from measured results.

I'm willing to lay odds that for your use cases the difference made by
accessors and mutators is not the low-hanging fruit.

Harmless optimizations that also strengthen code structure are always
acceptable, of course.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[Lew]

>> But I did not yet use it. Was just benchmarking my App and
>> saw that it runs much slower on Android. But that has also
>> to do with that I was using a tablet with something of 1GHz
>> ARM and was comparing against a 3.4GHz 64-bit Intel.

Oh, really? You think that just might have a teensy-weensy little bit to do
with the performance difference, just maybe?

I've worked a bit with Android code and deployment environments here and there.

No question, you have to be rather conservative of resources in Android, but
it's at the platform level for the most part, not the JVM level.

I am highly dubious of the claim that accessor/mutator time was the major
determinant of the putative performance issue.

Android deployments suffer from platform limitations - Jan mentioned one, the
slower ARM vs. the customary wideband desktop, usually multicore. The
programming model differs, too. Android is more like a Xen or other
virtualized meta-OS, with each Dalvik a different virtual host.

So things move in and out of memory differently - think of old-fashioned
memory overlays - than they do on the desktop. Applications move in and out of
memory on Android at the whim of Android, not Dalvik. You do have to bear this
in mind as you write for Android. For example, you have to be ready to resume
your application from a total shutdown at any instant, even just to change
orientation. You're far more bound to the UI than you might be used to.

Your GC is clunkier than Java SE's, and you sort of do have to watch your RAM,
and more importantly, your threads.

But RAM on a typical Android device ranges from a quarter gigabyte up. We're
not talking microwave-oven controllers, here. These are quite literally pocket
supercomputers. 1 GHz is slow? Come on!

Another factor is logging. Android has a syslog called "logcat", to which
everyone, their cousin and the family dog contributes. That surely affects
performance, and it makes it interesting to find your own log data amidst all
the noise.

How many of you are good at designing log output?

Liars. Of the ones who did not raise their hand, about half likely are good at
it. That's why they don't claim to be. The other half have a hope to be someday.

[Jan Burse]

Lew schrieb:

> I don't think I get your last paragraph here. What pain? What additional
> classes? Why?

The discussion was about some custom HashMap, call this
class XXX. If one does use inline loops such as:

for (int i = 0; i<table.length; i++) {
Entry e = table[i];
while (e!=null) {
/* do something */
}
}

The one does not need to defined an interator for the
custom HashMap, call this iterator class YYY.

These iterators which implement the interface Iterator
(or Enumerator) are usually not much visible Java collection
classes, since they are realized as inner classes.

But they add to the LOCs and the number of classes:

With Iterator Without Iterator
XXX N + K LOCs N LOCs
YYY M LOCs
Total N + K + M N

K is for the iterator factories inside the collection
class. Pain = N + K + M - N = K + M.

Since nobody would use class YYY anyway, since XXX
is anyway internal to the whole multi-indexing
framework and not visible by the client of the framework,
its not only a pain but also not a necessity.

> I'm willing to lay odds that for your use cases
> the difference made by accessors and mutators is
> not the low-hanging fruit.

For gambling you can go to Las Vegas, or if you
are up to something more serious, you could educate
yourself.

First of all originally Android didn't have a JIT.
See for example:
http://www.youtube.com/watch?v=ptjedOZEXPM
There might still be devices around without a JIT.

Second for my setter/getter claim you might want
to read this page:
http://developer.android.com/guide/practices/design/performance.html
There is a section about Avoid Internal Getters/Setters.

I copy the essential part for your eyes here:

"In native languages like C++ it's common practice to use getters (e.g.
i = getCount()) instead of accessing the field directly (i = mCount).
This is an excellent habit for C++, because the compiler can usually
inline the access, and if you need to restrict or debug field access you
can add the code at any time.

On Android, this is a bad idea. Virtual method calls are expensive, much
more so than instance field lookups. It's reasonable to follow common
object-oriented programming practices and have getters and setters in
the public interface, but within a class you should always access fields
directly.

Without a JIT, direct field access is about 3x faster than invoking a
trivial getter. With the JIT (where direct field access is as cheap as
accessing a local), direct field access is about 7x faster than invoking
a trivial getter. This is true in Froyo, but will improve in the future
when the JIT inlines getter methods."

Bye

[Jan Burse]

Jan Burse schrieb:

> Without a JIT, direct field access is about 3x faster than invoking a
> trivial getter. With the JIT (where direct field access is as cheap as
> accessing a local), direct field access is about 7x faster than invoking
> a trivial getter. This is true in Froyo, but will improve in the future
> when the JIT inlines getter methods."

Maybe an updated happened, but I didn't find a notice
about it. The last notice I found was:

http://android-developers.blogspot.com/2010/05/dalvik-jit.html
Which is already 2 years old!

The above blog post refers to Android 2.2,
which is Froyo.

Maybe somehow has found something newer?

Bye

[Lew]

And how much difference does that make to the application? 1%? 17%? 97%?

"3x faster" and "7x faster" at what level? Just the raw call to get the
attribute? In what usage scenario? At what load on the device?

The effect that has depends on how much those accessors are called. And what
is the cost to the application maintainability?

For a cost-benefit analysis you need to identify both the costs and the
benefits, and accurately, and relevantly.

[Lew]

On 05/12/2012 12:53 PM, Jan Burse wrote:
> Lew schrieb:
>> I don't think I get your last paragraph here. What pain? What additional
>> classes? Why?
>
> The discussion was about some custom HashMap, call this
> class XXX. If one does use inline loops such as:
>
> for (int i = 0; i<table.length; i++) {
> Entry e = table[i];
> while (e!=null) {
> /* do something */
> }
> }
>
> The one does not need to defined an interator for the
> custom HashMap, call this iterator class YYY.

If you have a custom 'HashMap', are you extending 'HashMap'?

You would have to avoid that if you are seeking to micromanage the class load.

> These iterators which implement the interface Iterator
> (or Enumerator) are usually not much visible Java collection
> classes, since they are realized as inner classes.
>
> But they add to the LOCs and the number of classes:
>
> With Iterator Without Iterator
> XXX N + K LOCs N LOCs
> YYY M LOCs
> Total N + K + M N
>
> K is for the iterator factories inside the collection
> class. Pain = N + K + M - N = K + M.
>
> Since nobody would use class YYY anyway, since XXX
> is anyway internal to the whole multi-indexing
> framework and not visible by the client of the framework,
> its not only a pain but also not a necessity.

I am not convinced that you are discussing real pain.

You seem to be claiming a reduction in class load, which if true might be
useful if it's significant. How much are you saving in class load?

> > I'm willing to lay odds that for your use cases
> > the difference made by accessors and mutators is
> > not the low-hanging fruit.
>
> For gambling you can go to Las Vegas, or if you
> are up to something more serious, you could educate
> yourself.

Oh, thank you for that, Mr. Snarky One.

Your points don't address mine, however.

You have yet to quote the statistics I requested.

What is the difference in *your* application?

I haven't lost my bet yet.

[Robert Klemme]

On Friday, May 11, 2012 1:41:49 AM UTC+2, Lew wrote:
> Arved Sandstrom wrote:
> > http://martinfowler.com/bliki/OrmHate.html
> >
> > Given some of the threads we've had...

Thank you for the link Arved!

> Now if all programmers who deal with object-to-relational mapping would
> only read it.

... and learn about their relational database. Very true.

Kind regards

robert

[Jan Burse]

Lew schrieb:

> You have yet to quote the statistics I requested.

I didn't do some measurements, should be
clear from my response to markspace, isn't it?

Bye

[Lew]

I responded to that post. The only facts you presented in evidence were that
your Android times were slower by some unspecified margin than the desktop
times, and that the Android platform was inherently physically slower than the
desktop.

I suggest that the platform differences, to which I alluded in some detail in
that response, account for the performance differences you observe, or could.
You need measurements that distinguish the effects of the platform from other
effects to know for sure.

At no point have you provided evidence here speaking to what in the
environments could account for the difference, or apportioning impact to known
factors such as the CPU speed and architecture differences.

You probably don't actually know what causes what proportion of the observed
(and undisclosed) difference. It is likely that the largest performance
differences are due to the sorts of factors I mentioned in my other response.

Why do I say "likely"? Because my own observations of Android applications and
my knowledge of the platform and experience with the balance of attribute
access via methods vs. other factors such as I/O, UI manipulation, thread
foobars and the like, I have seen more performance impact from the platform
effects than your suggested micro-optimization.

But I don't know for sure. I haven't got your numbers. It is possible that you
have evidence heretofore unshared that makes getters and setters the
low-hanging fruit after all. So, naturally, I request that you share that
evidence, at least in summary.

Whatever your numbers do show, it makes sense to work first on the matters
that make the biggest difference. If it's UI contention, work on that. If it
really is class load, work on that. If it's logger crud, work on that. What
you might wish to avoid is laboring intensely over an optimization that saves
one part in a thousand of time, causes much more maintenance work due to
workarounds and concomitant complexity induced by the fooferol, and is
obsoleted in a year by platform advances.

YMMV. But you might wish to educate yourself about where your actual problems lie.

[Fredrik Jonson]

Jan Burse wrote:

> If you don't use a device but an emulator, you also observe slowdown,
> since the Dalvik then runs inside the emulator (sic!).

From my perspectiv having the emulator run dalvik exactly like it would have on
on real devices is a good thing. I want device emulators being as close to
real world devices as possible, if not bug for bug compatible, then at least
having the same memory management pattern as a real device. And I'd definitively
trade some performance for more behaviour similarity.

You just need to learn to go get some coffee or stretch your legs while the
emulator boots. :)

--
Fredrik Jonson

[David Lamb]

On 13/05/2012 3:21 AM, Fredrik Jonson wrote:
> You just need to learn to go get some coffee or stretch your legs while the
> emulator boots. :)

Stretch your legs by walking to Columbia to pick the coffee beans.

[Arved Sandstrom]

On 12-05-10 09:03 PM, Arne Vajhøj wrote:

> On 5/10/2012 6:50 PM, Arved Sandstrom wrote:
>> http://martinfowler.com/bliki/OrmHate.html
>>
>> Given some of the threads we've had...
>

> What he says is certainly good, but I am not sure
> that it is all new. :-)

No, it's not new. Fowler's a respected commentator, though, and it's
good to get his fresh take on a topic. I don't always agree with him but
I think he's way more often right than he's wrong, and I've rarely read
anything by him that I'd dismiss out of hand.

> Using an ORM does 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
>
AHS

--
Never interrupt your enemy when he is making a mistake.
--Napoleon

[Lew]

jb wrote:
> Or for short:
> [expletives deleted].

That was uncalled-for. I assure you the information and ideas I presented are
both well grounded and intended to serve you. Why such a psychotic reaction to
a technical discussion?

It's a rhetorical question. I'm done with you. Buh-bye.

[Arne Vajhøj]

On 5/13/2012 5:11 AM, jb wrote:
> You are playing a very cheap game here. Turning a qualitative
> discussion into
> a quantitative discussion. And putting words into other peoples mouth.

You wrote:

#But I did not yet use it. Was just benchmarking my App and
#saw that it runs much slower on Android. But that has also
#to do with that I was using a tablet with something of 1GHz
#ARM and was comparing against a 3.4GHz 64-bit Intel.

Claiming that that qualitative a Java app is slower on X
than on Y can when X is in general slower than Y can be
abbreviated to "". It provides no real information.

Arne