Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PicoCache NSOperationQueue #4

Open
nobre84 opened this issue Oct 28, 2013 · 3 comments
Open

PicoCache NSOperationQueue #4

nobre84 opened this issue Oct 28, 2013 · 3 comments

Comments

@nobre84
Copy link

nobre84 commented Oct 28, 2013

Hi! I'm having a heavy load on PicoCache class when querying webservice calls concurrently inside NSOperationQueue, is this normal ? Can it be improved ?
For example, when queuing 20 operations (with a max concurrent size of 5), I get around 5000 NSLog calls to PicoCache objectForKey method, and I can see in the callstack many blocked operations on the @synchronized block to access it.
Can you suggest a way to improve concurrency? What is exactly that is cached here?

@nobre84
Copy link
Author

nobre84 commented Oct 28, 2013

PS: in fact i'm getting some sporadic crashes on this access too, but I can't be sure Pico code is to blame here...

@bulldog2011
Copy link
Owner

Hi,

PicoCache is used for obj-c to xml mapping metadata caching, it's only a simple LRU cache implementation without considering much concurrent performance issue.

In your case, as a workaround, you may try to disable cache by changing the pico source and re-build pico, the source file you need to change is:
https://github.com/bulldog2011/pico/blob/master/pico/PicoSource/Core/Schema/PicoBindingSchema.m
line 74 - 82, the fromClass method is so simple that I think you will have no problem to disable cache.

If schema cache is disabled, there will be no concurrent synchronization issue anymore, however, there may have a little performance penalty since the schema mapping needs to be re-built whenever needed, I haven't test this formally, you may have a try and see if the situlation can be improved, or, if possible, you may try to write a more efficient cache(LRU is not necessary if memory is not a problem in your case) and replace the one in Pico.

Thx!
-William

@nobre84
Copy link
Author

nobre84 commented Oct 30, 2013

Hi! For now I tried two things: to replace synchronized blocks with lower
level spin locks which are less heavy weight and instead of disabling
cache, I increased the number of PicoCache instances (one per Web Service
endpoint - in my use case we use 3 different services that gain nothing by
sharing a single cache)

The situation is much improved, but I still have (although much less
often), crashes in many points in Pico which fast enumerate on
NSMutableDictionary instances during parsing. I guess the cache may mutate
them from different threads once in a while (in a thread safe manner), but
the readings aren't being guarded against concurrent accesses. These are
many places, so it's not so easy to tinker with. I'll let you know how it
goes!
Thanks

Em 29/10/2013, às 14:04, bulldog notifications@github.com escreveu:

Hi,

PicoCache is used for obj-c to xml mapping metadata caching, it's only a
simple LRU cache implementation without considering much concurrent
performance issue.

In your case, as a workaround, you may try to disable cache by changing the
pico source and re-build pico, the source file you need to change is:
https://github.com/bulldog2011/pico/blob/master/pico/PicoSource/Core/Schema/PicoBindingSchema.m
line 74 - 82, the fromClass method is so simple that I think you will have
no problem to disable cache.

If schema cache is disabled, there will be no concurrent synchronization
issue anymore, however, there may have a little performance penalty since
the schema mapping needs to be re-built whenever needed, I haven't test
this formally, you may have a try and see if the situlation can be
improved, or, if possible, you may try to write a more efficient cache(LRU
is not necessary if memory is not a problem in your case) and replace the
one in Pico.

Thx!
-William


Reply to this email directly or view it on
GitHubhttps://github.com//issues/4#issuecomment-27316400
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants