-
Notifications
You must be signed in to change notification settings - Fork 35
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
Comments
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... |
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: 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! |
Hi! For now I tried two things: to replace synchronized blocks with lower The situation is much improved, but I still have (although much less Em 29/10/2013, às 14:04, bulldog [email protected] escreveu: Hi, PicoCache is used for obj-c to xml mapping metadata caching, it's only a In your case, as a workaround, you may try to disable cache by changing the If schema cache is disabled, there will be no concurrent synchronization Thx! — |
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?
The text was updated successfully, but these errors were encountered: