On Nov 16, 2007 7:37 AM, Debajyoti Bera [EMAIL PROTECTED] wrote:
Also, do you know if Dictionary offers a performance/memory benefit
over Hashtable? I found this which leads me to think it should be at
It shouldn't (when storing objects). If you are referring to a FIXME in
Oops, listing it
On Nov 16, 2007 7:15 AM, Kevin Kubasik [EMAIL PROTECTED] wrote:
I'm digging a little deeper to confirm this, I was just probing.
Also, do you know if Dictionary offers a performance/memory benefit
over Hashtable? I found this which leads me to think it should be at
least
Ok, on the FSQ thing, its far too dynamic to do something on-disk, we
would thrash it.
There is however a leak at FileSystemQueryable.cs 345, its not the
most horrid offender, but it can be one.
The real issue is the reflection/serialization stuff, some of this
might be mono issues, some might
Hi,
On 11/16/07, Kevin Kubasik [EMAIL PROTECTED] wrote:
p.s. Also, our in-memory hashtable of Guid's for the FSQ is immense,
it would be trivial to change the LuceneNameResolver to use a sqlite
db to store that data on-disk and out of memory, freeing a few megs. I
don't know a ton about the
Hi,
On 11/16/07, Kevin Kubasik [EMAIL PROTECTED] wrote:
The real issue is the reflection/serialization stuff, some of this
might be mono issues, some might be on us, but there are a ton of
strings hanging around in the XML serialization class libraries. There
are over 8,000 System.MonoType
On Nov 16, 2007 10:47 AM, D Bera [EMAIL PROTECTED] wrote:
There is however a leak at FileSystemQueryable.cs 345, its not the
most horrid offender, but it can be one.
You are referring about the comment about the leak there ? about the
hashtable name_info_by_id ? If that one, then its ok.
There is however a leak at FileSystemQueryable.cs 345, its not the
most horrid offender, but it can be one.
You are referring about the comment about the leak there ? about the
hashtable name_info_by_id ? If that one, then its ok. Its a known
issue, hard to implement and not really a leak. Is
