Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Good Fowler article on ORM

Reply
Thread Tools

Good Fowler article on ORM

 
 
Jan Burse
Guest
Posts: n/a
 
      05-12-2012
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/p...rformance.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



 
Reply With Quote
 
 
 
 
Jan Burse
Guest
Posts: n/a
 
      05-12-2012
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.c...alvik-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
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      05-12-2012
Jan Burse wrote:
> 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.c...alvik-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?


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
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      05-12-2012
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.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      05-12-2012
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
 
Reply With Quote
 
Jan Burse
Guest
Posts: n/a
 
      05-12-2012
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
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      05-13-2012
Jan Burse wrote:
> 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?


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.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
Fredrik Jonson
Guest
Posts: n/a
 
      05-13-2012
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
 
Reply With Quote
 
jb
Guest
Posts: n/a
 
      05-13-2012
Hi Lew,

> But I don't know for sure.


You are playing a very cheap game here. Turning a qualitative
discussion into
a quantitative discussion. And putting words into other peoples mouth.

Assume I have stated that something exists, this is like saying x>0.
Now you go on pondering on the degree of the existence, in that you
blaming me for not displaying a margin m, effective value e and
verification e>m.

Who are you to change the intent of my communication? If you are
interested in m, e than do your own research. I gave you the evidence
for >0 by reference to the Android. I wish that you do not anymore
disturbe my post in the future in this way.

Or for short:
Suck my dick, shut up and **** off.

 
Reply With Quote
 
David Lamb
Guest
Posts: n/a
 
      05-13-2012
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
rBATIS - alternative ORM for Ruby / Rails (via Martin Fowler) vasudevram Ruby 0 08-10-2006 04:00 PM
ORM Chris Kennedy MCSD 0 09-06-2005 03:09 AM
[Slightly OT] Martin Fowler demystifying closures Gavri Savio Fernandez Ruby 3 09-10-2004 07:20 PM
ORM resources necessary for 70-300 TomTom MCSD 7 08-17-2004 07:08 AM
Martin Fowler and Ruby Weirich, James Ruby 6 09-29-2003 06:49 PM



Advertisments