• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Managing EOF caching
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Managing EOF caching


  • Subject: Re: Managing EOF caching
  • From: Michael DeMan <email@hidden>
  • Date: Fri, 20 Jan 2006 14:54:51 -0800

Hi Jerry,

A couple of other items off the top of my head in order to manage your memory utilization as you start trying to take advantage of the EOF caching...

1. assuming you are not using undo().

defaultEditingContext().undoManager().setLevelsOfUndo(1);


2. On your snapshots, the method you want to drop that to less than an hour for refresh is:


defaultEditingContext().setFetchTimestamp()

It used to be that EOF still did not flush out the snapshots correctly but I believe that was fixed a couple of years ago.


Apple badly needs to get a Tech Bulletin on EOF memory and performance optimization. There are probably a few hundred people at most with deep WO/EOF experience on this stuff and they all have their bag of tricks and nobody knows each other's tricks that well and all the tricks have one caveat or another. WO works great for small apps, but the minute you get a decent sized application the tuning becomes an issue.



On Jan 20, 2006, at 10:20 AM, Jerry W. Walker wrote:

Hi, Mike,

Thanks for taking the time to do this.

If I understand your test correctly, in each of the two cases, you've looped through the 10,000 EOs updating a single one of your 12 attributes. You then did a saveChanges to update the database, resulting in 10,000 individual SQL updates hitting the database, correct?

So, the result was 10,000 round trips to the DB, one for each row updated?

If all of that is correct, and if it's a trivial change to test, would it be possible to test the difference between a SINGLE locked column vs all columns locked?

You've taken the time to do something helpful here and I don't want to reward you by suggesting you need to do a lot more work, but the test I'm suggesting would put the results more in line with the original contention, that locking a single attribute saves a significant amount over locking all the attributes (in your case, 12).

If you would rather not take the tests any further, would you mind sending me a tarball of your current test project? I would be pleased to do it.

If all of the above is correct, your results say that the difference for a single update is approximately:

27.753 sec / 10,000 = 2.7 ms / update

     vs.

7.111 / 10,000 = .7 ms / update

So we've achieved a 2 ms savings per update between no checking and checking 12 columns.

If that's the case, my untested (ignorant?) opinion that the difference is insignificant (and is probably less than 10 ms) stands corrected. Much as I hate to be wrong, my yearning for facts over both my ignorant opinions and other WO "old wive's tales" leads me to offer you unequivocal thanks for your efforts.

Regards,
Jerry

On Jan 20, 2006, at 12:54 PM, Mike Schrag wrote:


I haven't done any timings, but I find it hard to believe that this technique will effect any significant savings for most databases. As Art indicates, the only effect of reducing the number of lock columns is to correspondingly reduce the number of columns in the WHERE clause for updates and deletes.
I've always wondered this, too, so I threw together a quick test. I created two identical entities which have 3 ints, 3 booleans, 3 strings, and 3 dates as properties, but one locks all attrs and one locks none. I then inserted 10,000 of each into the db, followed by an update of the same attribute for each with the same change in value.

This was run on the latest version of FrontBase on an Intel iMac with WO 5.3:

Main.main: 10000 with all columns locked = 25753ms
Main.main: 10000 with no columns locked = 7111ms

So in this test, it is 3.6x faster to not lock any columns in this example, with this database, one this hardware. Obviously db benchmarks are never this simple, so take this with a grain of salt.

ms



--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial Strength Internet Enabled Systems


    email@hidden
    203 278-4085        office



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40geminisolutions.com


This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Managing EOF caching
      • From: Art Isbell <email@hidden>
    • Re: Managing EOF caching
      • From: "Jerry W. Walker" <email@hidden>
References: 
 >RE: Managing EOF caching (From: Dave Rathnow <email@hidden>)
 >Re: Managing EOF caching (From: Michael DeMan <email@hidden>)
 >Re: Managing EOF caching (From: Art Isbell <email@hidden>)
 >Re: Managing EOF caching (From: "Jerry W. Walker" <email@hidden>)
 >Re: Managing EOF caching (From: Mike Schrag <email@hidden>)
 >Re: Managing EOF caching (From: "Jerry W. Walker" <email@hidden>)

  • Prev by Date: Re: Managing EOF caching
  • Next by Date: Re: Managing EOF caching
  • Previous by thread: Re: Managing EOF caching
  • Next by thread: Re: Managing EOF caching
  • Index(es):
    • Date
    • Thread