Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #14461 > unrolled thread

Good Fowler article on ORM

Back to article view | Back to comp.lang.java.programmer

Contents

  Good Fowler article on ORM Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-10 19:50 -0300
    Re: Good Fowler article on ORM Roedy Green <see_website@mindprod.com.invalid> - 2012-05-10 16:52 -0700
      Re: Good Fowler article on ORM Arne Vajhøj <arne@vajhoej.dk> - 2012-05-10 20:10 -0400
      Re: Good Fowler article on ORM Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-05-11 01:56 -0500
      Re: Good Fowler article on ORM Jan Burse <janburse@fastmail.fm> - 2012-05-11 10:06 +0200
        Re: Good Fowler article on ORM Jan Burse <janburse@fastmail.fm> - 2012-05-11 10:09 +0200
        Re: Good Fowler article on ORM David Lamb <dalamb@cs.queensu.ca> - 2012-05-11 21:56 -0400
          Re: Good Fowler article on ORM Jan Burse <janburse@fastmail.fm> - 2012-05-12 12:01 +0200
            Re: Good Fowler article on ORM David Lamb <dalamb@cs.queensu.ca> - 2012-05-12 06:22 -0400
              Re: Good Fowler article on ORM Jan Burse <janburse@fastmail.fm> - 2012-05-12 13:14 +0200
                Re: Good Fowler article on ORM Jan Burse <janburse@fastmail.fm> - 2012-05-12 13:27 +0200
                Re: Good Fowler article on ORM markspace <-@.> - 2012-05-12 08:15 -0700
                  Re: Good Fowler article on ORM Jan Burse <janburse@fastmail.fm> - 2012-05-12 18:21 +0200
                    Re: Good Fowler article on ORM markspace <-@.> - 2012-05-12 10:37 -0700
                      Re: Good Fowler article on ORM Lew <noone@lewscanon.com> - 2012-05-12 12:27 -0700
                    Re: Dalvik running on the Android device emulator Fredrik Jonson <fredrik@jonson.org> - 2012-05-13 07:21 +0000
                      Re: Dalvik running on the Android device emulator David Lamb <dalamb@cs.queensu.ca> - 2012-05-13 08:18 -0400
                Re: Good Fowler article on ORM Lew <noone@lewscanon.com> - 2012-05-12 12:12 -0700
                  Re: Good Fowler article on ORM Jan Burse <janburse@fastmail.fm> - 2012-05-12 21:53 +0200
                    Re: Good Fowler article on ORM Jan Burse <janburse@fastmail.fm> - 2012-05-12 21:59 +0200
                      Re: Good Fowler article on ORM Lew <noone@lewscanon.com> - 2012-05-12 13:55 -0700
                    Re: Good Fowler article on ORM Lew <noone@lewscanon.com> - 2012-05-12 13:59 -0700
                      Re: Good Fowler article on ORM Jan Burse <janburse@fastmail.fm> - 2012-05-12 23:49 +0200
                        Re: Good Fowler article on ORM Lew <noone@lewscanon.com> - 2012-05-12 17:14 -0700
                          Re: Good Fowler article on ORM jb <janburse@fastmail.fm> - 2012-05-13 02:11 -0700
                            Re: Good Fowler article on ORM Lew <noone@lewscanon.com> - 2012-05-14 22:25 -0700
                            Re: Good Fowler article on ORM Arne Vajhøj <arne@vajhoej.dk> - 2012-05-20 22:15 -0400
    Re: Good Fowler article on ORM Arne Vajhøj <arne@vajhoej.dk> - 2012-05-10 20:03 -0400
      Re: Good Fowler article on ORM Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 18:40 -0700
        Re: Good Fowler article on ORM Arne Vajhøj <arne@vajhoej.dk> - 2012-05-10 21:42 -0400
      Re: Good Fowler article on ORM Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-13 19:40 -0300
    Re: Good Fowler article on ORM markspace <-@.> - 2012-05-10 19:17 -0700
    Re: Good Fowler article on ORM Lew <lewbloch@gmail.com> - 2012-05-10 16:41 -0700
      Re: Good Fowler article on ORM Robert Klemme <shortcutter@googlemail.com> - 2012-05-12 14:33 -0700

Page 2 of 2 — ← Prev page 1 [2]

#14495

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

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/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#14496

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/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#14497

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

[toc] | [prev] | [next] | [standalone]

#14498

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/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#14527

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

[toc] | [prev] | [next] | [standalone]

#14541

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.

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

[toc] | [prev] | [next] | [standalone]

#14697

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

[toc] | [prev] | [next] | [standalone]

#14464

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

[toc] | [prev] | [next] | [standalone]

#14470

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 ;-)

[toc] | [prev] | [next] | [standalone]

#14471

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

[toc] | [prev] | [next] | [standalone]

#14503

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

[toc] | [prev] | [next] | [standalone]

#14473

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.

[toc] | [prev] | [next] | [standalone]

#14517

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

[toc] | [prev] | [next] | [standalone]

#14526

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web