>> I had to change the directory data source to
>> use synchronous proxy observers just like the js
>> LDAP data source so it can be really slow.
>
>I don't really understand why the JS datasource uses sync proxies
>(peterv?). Given that this is really a callback, and there's no
>interesting way to recover from an error in a callback, it seems
>like async (fire & forget) would be fine. On the other hand, using
>async proxies is probably more likely to subject us to event queue
>flooding if there are a lot of entries (like bug 50104). Anyone, you
>could conceivably try switching one or both of these proxies to being
>async and see whether things get better or worse.
>
If you use async then the GUI becomes very sluggish
in debug, not sure what its like in release, as per
bug 50104.
I am testing against an internal LDAP server which
contains all Sun employee info, so it is very
responsive.
Also modified the ds so that non proxy RDF observers
are used for synchronous address books.
I do this by checking if the current thread
is equal to the main thread (which is the
UI thread):
nsCOMPtr<nsIThread> currentThread;
rv = nsIThread::GetCurrent (getter_AddRefs(currentThread));
NS_ENSURE_SUCCESS (rv, rv);
nsCOMPtr<nsIThread> uiThread;
rv = nsIThread::GetMainThread (getter_AddRefs(uiThread));
NS_ENSURE_SUCCESS (rv, rv);
nsCOMPtr<nsISupportsArray> observers;
if (currentThread == uiThread)
{
}
else
{
}
I presume this will be OK in the future.
i.e. the ui thread will always be the main
thread...
>> Getting 100 address book entries is about 5x slower
>> using a debug mozilla build than 4.x,
>> .... but it works!
>
>This is great! It'll be interesting to see how much faster this is on
>a release build.
>
Yep!.
Thanks,
Paul.
| ? + ? = To question
----------------\
Paul Sandoz
x19219
+353-1-8199219
