[Mono-osx] [Mono-dev] OS X builds and -DUSE-MUNMAP

[Eoin Norris]

>

Hmm. I am not so sure that this has made it, or works as advertised.  
i can see - in loading in a very large xml file -

Take this function

	public void PopulateXMLString()
		{
			try
			{
				// Open xml file
				XmlDocument doc = new XmlDocument();
				
				// Turn off external url resolving (e.g. for schema validation)
				doc.XmlResolver = null;

				doc.LoadXml(_libraryXmlString);

				// Read version
				_version = doc.SelectSingleNode(XmlNode_PList).Attributes 
[XmlAttr_Version].Value;
				if (_version != SupportedVersion) throw new FormatException("Can  
only decode version 1.0 specification files!");
				
				// My Decode dict ( internal class)
				_contents = Dict.Decode(doc.SelectSingleNode(XmlNode_PList + '/'  
+ XmlNode_Dict));
			}
			catch (System.Threading.ThreadAbortException)
			{
...
			}
			catch (Exception ex)
			{
			...
			}
		}

This bloats to 200MB when reading a 23MB xml file - mostly in  
doc.LoadXml(_libraryXmlString) as far as I can see ( although without  
a full debugger it is hard to tell) . I have also would do the same  
if it were read from disk at this point,   a process that is too slow  
in any case, so I load in the Cocoa layer instead.

( i.e. to read fom disk I can use :

				using (FileStream s = _libraryXmlFile.OpenRead())
				{
					doc.Load(s);
				}

with the same results in terms of memory consumption, or worse)


The size increase is possibly a bug in itself, since the .Net side on  
windows doing similar code does not bloat to that level.

In any case the object that encapsulates this functionality does not  
need to hang around after it's contents are written to a different  
datastore.

so I blow it away like so

	if (xmlString.Length != 0)
		library.PopulateXMLString();

.. do stuff with the library contents

	library = NULL;
	GC.Collect();


The specific call to GC.Collect is just a test case, not normally in  
production code. In any case the code bloats and stays bloated. So I  
dont think that this fix has made it, unless I am doing somthing  
wrong :-)

  Were I to download the sources, where should I look to see if this  
is in the suggested sources i.e. 1.2.2.1 ? Is there a way to tell  
from the dlls ( I suspect not).

I should add this is really a deal breaker in terms of releasing the  
product, as you can imagine not releasing large amounts of memory is  
a big issue.

thanks in advance.

-- Eoin






> According to your quote it's committed, thus likely in 1.2.2 (Dec
> 6th). There is no 2.1 just yet. :-)
>
> Andreas
>
>
> On 11 Jan 2007, at 12:11, Eoin Norris wrote:
>
>> Is this scheduled for a release anytime soon, is it in 2.1?
>>
>> -- Eoin
>>
>>
>> On 2 Dec 2006, at 00:07, Allan Hsu wrote:
>>
>>>
>>> On Dec 1, 2006, at 2:55 PM, Miguel de Icaza wrote:
>>>
>>>> Hello,
>>>>
>>>>> Nobody has objected to turning on -DUSE_MUNMAP under OS X since I
>>>>> posted this email... Can somebody give me the go-ahead to  
>>>>> commit the
>>>>> configure.in change needed to switch over?
>>>>
>>>> Go ahead.
>>>
>>> Committed.
>>>
>>> --
>>> Allan Hsu <allan at counterpop dot net>
>>> 1E64 E20F 34D9 CBA7 1300  1457 AC37 CBBB 0E92 C779
>>
>>
>> _______________________________________________
>> Mono-osx mailing list
>> Mono-osx at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-osx
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-osx/attachments/20070124/5c824f1a/attachment-0001.html