Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Hi, We have a lot of small test cases in SVN and only few of them is expected to fail so if you need small sources you can use nearly any of the test cases in SVN: http://svn.myrealbox.com/viewcvs/trunk/vbnc/vbnc/tests/ Also note that previously I attached a relatively small but functional program written in VB that can be compiled using vbnc: http://lists.ximian.com/pipermail/mono-devel-list/2006-October/021165.html Thanks you and everyone in this thread for telling me about profiling now I understand that using small sources is easier. Kornél - Original Message - From: Miguel de Icaza [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED] Cc: Paolo Molaro [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com Sent: Wednesday, November 01, 2006 6:19 AM Subject: Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono Hello, Sorry if I don't understand what you need but I have no experience in profiling Mono. What is the sample program that you need? Sorry but I really didn't understand what exactly you need. The profiler today only runs when the program exists successfully, so we need a shorter test case, something that will not take one hour to build, but something that will take, say, a minute to build. Once we have something that takes a minute to build (or even 10 seconds instead of instantaneous builds) we can start looking where the memory went. My take is that probably building a chunk of the VB runtime is probably good enough for this. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Hello, Any help on speeding up vbnc is welcome. First I'd like to apoligize for leaving this unanswered for so many days, the problem was that my motherboard went up in smoke and I had to get a new computer :( It seems that the linked list for *all* files was kept for the *entire* duration of the gc, from my profiling on windows. Rolf, can you confirm this? The compiler is effectively keeing a linked list of all the tokens, and it keeps them until the compiler finishes (tokens are kept since they contain the source location for the token and would be necessary for any error messages.) I'm quite sure I can remove the entire list pretty easily though, so I'll try to fix this as soon as possible. However I don't think this is the real problem, after parsing the source the list is never walked, and then the only bottle-neck I can see would be the gc to take too long to walk the list in order to decide that it cannot be disposed of, but since Kornél's added gc collections and it worked better this does not really seem logical. What I do know is that the compiler creates a huge number of temporary objects while compiling, and in my opinion this hurts the mono gc more (and this would match the fact that adding gc collections was making it better). Anyway, here are a few ideas of optimizations: - I think some class is implementing a finalizer (don't remember which), this can be probably just be removed or commented out. - Helper.ResolveGroup is called quite frequently and it creates a large number of temporary objects. I think this method should be changed, but it is one of the most complicated methods in the compiler, so it has to be done carefully. (I didn't profile this though). - Helper.GetOverloadableSignatures creates a large number of strings (I profiled this), so this might be changed somehow. - When a member lookup is done on a type, the compiler loads all the members of the type in question and all the ascendent types in order to create a flattened view of the type, and then the flattened type is cached. It might be better to load only the required member on the type and it's ascendent types and cache that. This is a somewhat bigger change though. - When the scanner needs more source code, the entire source file is loaded into memory and the contents are scanned sequentially like an array. An idea might be to change it to be a more stream-like scanning of characters. I don´t know how much this will gain though, since the scanning part only takes a couple of seconds anyway. I will also check if the vbruntime can be used as a better test case for performance than vbnc (it's smaller at least), and I think something more complicated than Hello World is necessary to profile performance. Rolf -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Hello, The compiler is effectively keeing a linked list of all the tokens, and it keeps them until the compiler finishes (tokens are kept since they contain the source location for the token and would be necessary for any error messages.) I'm quite sure I can remove the entire list pretty easily though, so I'll try to fix this as soon as possible. However I don't think this is the real problem, after parsing the source the list is never walked, and then the only bottle-neck I can see would be the gc to take too long to walk the list in order to decide that it cannot be disposed of, but since Kornél's added gc collections and it worked better this does not really seem logical. MCS works like this, the tokenizer as I mentioned is called by the parser as it needs to parse the tokens, each time its called, it returns one token or end of file (which is another kind of token). For each token returned, the tokenizer keeps a bit of state, called the Location which happens to be an Int32, and in that Int32 we encode the filename, row and location (see mcs/location.cs for details on the encoding). This is important for a few reasons: locations are structs, so they are very light weight, and they fit nicely into 1-word, which is very efficient as well. Now, during parsing we call the tokenizer to identify the next token, and the tokenizer returns this 32 bit value. The parser makes a decision based on that and if the parser needs to construct some element that needs to track the location, it checks a public property in the tokenizer, the Location that reports the location where the current token was found. This means that for each parsed component we only track one location (we might have a few cases where we store more than one location, but they are rare). So tokens are effectively discarded as soon as the parser has made a decision, and locations are tracked in each internal node that we create, and only when we actually need them (our base Statement and Expression classes have a Location field, so we use this to track the location). When I wrote mcs, I thought that creating many objects would be a source of problems (I was in particular worried about all the implicit and explicit cast objects that we created). But it turned out that those objects never showed up in a profile, the major issues were all the lists that we created in FindMembers, the overload method resolution (we create lots of arrays that we never reuse) and most importantly, lots of string operations that were concatenating namespaces and types ns + . + type kind of operations. - When a member lookup is done on a type, the compiler loads all the members of the type in question and all the ascendent types in order to create a flattened view of the type, and then the flattened type is cached. It might be better to load only the required member on the type and it's ascendent types and cache that. This is a somewhat bigger change though. Some inspiration could probably be taken from the MCS MemberCache routine, it was designed precisely because of this issue. Am not sure if it solves it in a way that is compatible with vbnc, am afraid it might not, but its worth a look. Also, this is a bit of an advanced optimization, so as you point out, this probably can wait. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
On 10/29/06 Kornél Pál wrote: I'll probably be able to fix that one as well, but my very-very big problem is that vbnc is so undarebly slow on Mono that it's quite impossible to wait for the compiler to reach again the stage where it's failing. If the results of previous stages could be serialized it could save a lot of time and the actual stage could be debugged. This is not going to happen, because it involves a lot of work and doesn't solve any problem. There are two issues here: *) vbnc's implementation makes it very slow *) vbnc running on mono hits some codepaths that makes it even slower than it is already Any help on speeding up vbnc is welcome. Someone should provide a current vbnc binary and any assemblies it depends on so that it runs on the current svn version of mono. Please do not include the ugly additional GC thread hack. Also include a largish VB program that vbnc can compile (in, say, 10-20 seconds on the MS runtime). When that is available, we can profile it on Linux and see where it spends all that time and why. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Any help on speeding up vbnc is welcome. Ben got the impression that VBNC was keeping a linked list of all the tokens after the tokenization phase (which is brutal on the GC as it becomes a large link-list walk). In my opinion, instead of having a tokenization phase that keeps all the tokens in memory and then a second stage that walks this list, we should turn the compiler into a parser that calls the tokenizer and pulls tokens from it on demand (like mcs does). This would avoid keeping the huge list around, and would eliminate a phase. Alternatively, a quick hack might be to clear the tokens after the parsing (but am guessing here that the data is not used afterwards). Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
On 10/31/06 Miguel de Icaza wrote: Any help on speeding up vbnc is welcome. Ben got the impression that VBNC was keeping a linked list of all the tokens after the tokenization phase (which is brutal on the GC as it becomes a large link-list walk). While that is clearly a very inefficient way to do things, we can't say it is the issue that is making vbnc unusable especially in mono. First, it depends if the tokens are kept for the whole source or just one file at a time: in the latter case it should not be so bad, since the vbnc compiler is spread over hundreds of tiny files, so the actual memory usage should be limited. Besides a non-moving GC can be faster at handling such long lists than a moving one (one of my long-linked-list stress tests for the new GC runs about two times slower on the jvm gc and about 30% slower on the mono sgen GC vs the Boehm GC). It may be more of an issue that the source is spread in so many files. Does the code properly dispose the file strem objects as sson as tokenization is done? Anyway, it would be better to have the binaries and sample programs so that we can actually profile on linux and see where time is actually spent instead of guessing. The token list might be a problem, but it might also be a tiny part of the whole picture. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
On 10/31/06 Miguel de Icaza wrote: Any help on speeding up vbnc is welcome. Ben got the impression that VBNC was keeping a linked list of all the tokens after the tokenization phase (which is brutal on the GC as it becomes a large link-list walk). While that is clearly a very inefficient way to do things, we can't say it is the issue that is making vbnc unusable especially in mono. First, it depends if the tokens are kept for the whole source or just one file at a time: in the latter case it should not be so bad, since the vbnc compiler is spread over hundreds of tiny files, so the actual memory usage should be limited. Besides a non-moving GC can be faster at handling such long lists than a moving one (one of my long-linked-list stress It seems that the linked list for *all* files was kept for the *entire* duration of the gc, from my profiling on windows. Rolf, can you confirm this? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Is there a sample app the compiles slowly somewhere (and instructs on how to use VBNC) that i can download it and run a few tests myself to see if i could lend a hand? I'm interested in this kind of stuff, but probably won't be able to help much :p But i'll try. Thanks,Alan.On 10/31/06, Ben Maurer [EMAIL PROTECTED] wrote: On 10/31/06 Miguel de Icaza wrote: Any help on speeding up vbnc is welcome. Ben got the impression that VBNC was keeping a linked list of all the tokens after the tokenization phase (which is brutal on the GC as it becomes a large link-list walk). While that is clearly a very inefficient way to do things, we can't say it is the issue that is making vbnc unusable especially in mono. First, it depends if the tokens are kept for the whole source or just one file at a time: in the latter case it should not be so bad, since the vbnc compiler is spread over hundreds of tiny files, so the actual memory usage should be limited. Besides a non-moving GC can be faster at handling such long lists than a moving one (one of my long-linked-list stressIt seems that the linked list for *all* files was kept for the *entire*duration of the gc, from my profiling on windows. Rolf, can you confirm this?___Mono-devel-list mailing listMono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
[Not approving the 700KB mail message to the list, just replying to some comments here] On 10/31/06 Kornél Pál wrote: Does the code properly dispose the file strem objects as sson as tokenization is done? http://svn.myrealbox.com/viewcvs/trunk/vbnc/vbnc/source/General/CodeFile.vb?rev=64447view=markup The entire file is read and then is stored as a string. (This was the same before my UTF-8 detection patch.) It looks like the file is closed on finally, so that's good. It seems also that the token list is kept just while a single file is parsed, so that should not be too bad. What is worrying is that it seems the list is also used as an array, with indexing by integer and this may have a significant impact on performance. gain, we can't tell for sure until someone provides a sample program as requested. Anyway, it would be better to have the binaries and sample programs so that we can actually profile on linux and see where time is actually spent instead of guessing. The token list might be a problem, but it might also be a tiny part of the whole picture. Is that a problem if the compilation cannot complete? Currently vbnc is able to finish the resolve phase on Mono when bootstrapping and fails in early define phase. How much time does it take to complete the resolve phase? I thought that was the issue given this thread subject. If there are other issues, they should be discussed in another thread. And yes, it is a problem if it makes the compiler so slow to be unusable as you claim it is. You need Mono SVN HEAD. Microsoft.VisualBasic.dll can be used from Mono 1.1.18 installer. And you need the corlib/runtime patch in http://lists.ximian.com/pipermail/mono-devel-list/2006-October/021093.html in order to finish resolve phase. After resolve phase I have no experience because it takes too long time to finish resolve and that makes quite impossible to debug the define phase on Mono. This is why I requested a sample program that can compile, instead of trying to profile a program that never finishes. When someone posts that we can start to profile, so far nobody did, I guess we have to wait for some vb programmers to show up. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Is that a problem if the compilation cannot complete? Currently vbnc is able to finish the resolve phase on Mono when bootstrapping and fails in early define phase. How much time does it take to complete the resolve phase? I thought that was the issue given this thread subject. If there are other issues, they should be discussed in another thread. And yes, it is a problem if it makes the compiler so slow to be unusable as you claim it is. The resolve phase is part of compilation so the subject covers the problem. When doing bootstrap (compiling vbnc using vbnc) finishing the resolve phase takes up to 2 minutes on MS.NET. Doing the same on Mono takes at least 1 hour on the same machine. So I think it's worth to profile the bootstrap altough it cannot finish further phases yet. If that's a problem simply abort compilation arfter resolve phase is finished. This is why I requested a sample program that can compile, instead of trying to profile a program that never finishes. When someone posts that we can start to profile, so far nobody did, I guess we have to wait for some vb programmers to show up. I guess that vbnc is not able to finish compiling other huge programs just like itself. But I can't fix SRE to support vbnc because it takes at least 1 hour to reach the point when it fails that makes debugging and probing patches quite impossible. I think that you could profile the vbnc bootstrap until the end of resolve phase because it requires a lot of time and memory by itself. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
On 10/31/06 Kornél Pál wrote: The resolve phase is part of compilation so the subject covers the problem. When doing bootstrap (compiling vbnc using vbnc) finishing the resolve phase takes up to 2 minutes on MS.NET. Doing the same on Mono takes at least 1 hour on the same machine. So I think it's worth to profile the bootstrap altough it cannot finish further phases yet. If that's a problem simply abort compilation arfter resolve phase is finished. Well, I'm not going to waste time with this thread anymore, since you are not willing to understand or to cooperate. I asked for a program that takes less than that to compile, because it's obvious that trying to profile that is idiotic and a complete waste of time. Is that so hard to get through? Have fun. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Well, I'm not going to waste time with this thread anymore, since you are not willing to understand or to cooperate. I asked for a program that takes less than that to compile, because it's obvious that trying to profile that is idiotic and a complete waste of time. Is that so hard to get through? Sorry if I don't understand what you need but I have no experience in profiling Mono. What is the sample program that you need? Sorry but I really didn't understand what exactly you need. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
What he needs and i need and anyone else who wants to help with this issue needs is a program that takes 5-15 minutes to compile using VBNC. Trying to profile a 1 hour compile that crashes is a waste of time. Profiling for 10 minutes allows reasonalby fast results when testing a new patch. Making a change that makes compiling 20% faster will be next to impossible to detect on a compile that takes over an hour and crashes. So, as soon as i see a smallish program and instructs on compiling i'll take a look at the issue. Other than that, i'll just watch the thread. I'm not going to go hunting for ages trying to find sample apps. I don't use VBNC, i don't care whether it works or not, but if i am handed a sample app with instructions, i will try to make it faster. Thanks,Alan.On 10/31/06, Kornél Pál [EMAIL PROTECTED] wrote: Well, I'm not going to waste time with this thread anymore, since you arenot willing to understand or to cooperate. I asked for a program that takesless than that to compile, because it's obvious that trying to profile that is idiotic and a complete waste of time. Is that so hard to get through?Sorry if I don't understand what you need but I have no experience inprofiling Mono.What is the sample program that you need? Sorry but I really didn't understand what exactly you need.Kornél___Mono-devel-list mailing listMono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
This is a small program that wraps normal executable to be services.
Compile using:
mono --debug vbnc.exe /reference:System.dll,System.ServiceProcess.dll
ServiceHost.vb
vbnc is able to successfully compile this program.
Hope this helps.
If you need small programs, you may want to try the files in
trunk/vbnc/vbnc/tests.
Kornél
- Original Message -
From: Alan McGovern [EMAIL PROTECTED]
To: mono-devel-list@lists.ximian.com
Sent: Tuesday, October 31, 2006 10:59 PM
Subject: Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
What he needs and i need and anyone else who wants to help with this issue
needs is a program that takes 5-15 minutes to compile using VBNC. Trying to
profile a 1 hour compile that crashes is a waste of time. Profiling for 10
minutes allows reasonalby fast results when testing a new patch. Making a
change that makes compiling 20% faster will be next to impossible to detect
on a compile that takes over an hour and crashes.
So, as soon as i see a smallish program and instructs on compiling i'll take
a look at the issue. Other than that, i'll just watch the thread. I'm not
going to go hunting for ages trying to find sample apps. I don't use VBNC, i
don't care whether it works or not, but if i am handed a sample app with
instructions, i will try to make it faster.
Thanks,
Alan.
On 10/31/06, Kornél Pál [EMAIL PROTECTED] wrote:
Well, I'm not going to waste time with this thread anymore, since you are
not willing to understand or to cooperate. I asked for a program that
takes
less than that to compile, because it's obvious that trying to profile
that
is idiotic and a complete waste of time. Is that so hard to get through?
Sorry if I don't understand what you need but I have no experience in
profiling Mono.
What is the sample program that you need? Sorry but I really didn't
understand what exactly you need.
Kornél
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Option Strict On
Imports ControlChars = Microsoft.VisualBasic.ControlChars
Imports System
Imports System.Diagnostics
Imports System.IO
Imports System.Runtime.InteropServices
Imports System.ServiceProcess
Imports System.Threading
Namespace ServiceHost
Friend NotInheritable Class ServiceHost
Inherits ServiceBase
Private Shared ArgSeparators As Char()
Private Shared CmdAutoStart As Boolean
Private Shared CmdPriority As ProcessPriorityClass
Private Shared CmdFileName As String
Private Shared CmdArguments As String
Private AutoStart As Boolean
Private Priority As ProcessPriorityClass
Private FileName As String
Private Arguments As String
Private WorkingDirectory As String
Private Process As Process
Shared Sub New()
ArgSeparators = New Char() { c, ControlChars.Tab}
End Sub
Private Sub New()
MyBase.New()
Me.ServiceName = ServiceHost
Me.CanStop = True
Me.EventLog.Source = Service Host
Me.AutoLog = False
End Sub
MTAThread() _
Public Shared Sub Main()
Dim Index As Integer
Dim CommandLine As String
Dim ArgName As String
CmdPriority = ProcessPriorityClass.Normal
CommandLine = Environment.CommandLine
If CommandLine.Chars(0) = c Then
Index = CommandLine.IndexOf(c, 1)
Else
Index = CommandLine.IndexOfAny(ArgSeparators)
End If
If Index 0 AndAlso Index + 1 CommandLine.Length Then
CommandLine = CommandLine.Substring(Index +
1).TrimStart(ArgSeparators)
Do While CommandLine.StartsWith(-)
Index = CommandLine.IndexOfAny(ArgSeparators, 1)
If Index = 0 Then
ArgName = CommandLine.Substring(0, Index).ToLower
Else
ArgName = String.Empty
End If
If Index + 1 = CommandLine.Length Then
CommandLine = String.Empty
Else
CommandLine = CommandLine.Substring(Index +
1).TrimStart(ArgSeparators)
End If
If ArgName.Equals(-autostart) Then
CmdAutoStart = True
ElseIf ArgName.Equals(-highpriority) Then
CmdPriority = ProcessPriorityClass.High
ElseIf ArgName.Equals(-lowpriority) Then
CmdPriority = ProcessPriorityClass.Idle
End If
Loop
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
On Tue, 2006-10-31 at 22:52 +0100, Kornél Pál wrote: Well, I'm not going to waste time with this thread anymore, since you are not willing to understand or to cooperate. I asked for a program that takes less than that to compile, because it's obvious that trying to profile that is idiotic and a complete waste of time. Is that so hard to get through? Sorry if I don't understand what you need but I have no experience in profiling Mono. What is the sample program that you need? Sorry but I really didn't understand what exactly you need. He needs Hello World: Imports System Public Module HelloWorld Public Shared Sub Main () Console.WriteLine (Hello, World!) End Sub End Module I don't know VB, so that probably won't work, but he needs a *small* VB source program that doesn't take 1 hour to compile, but instead (preferably) takes 1 minute. If Hello World can't be compiled in a reasonable time frame, then Ouch. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Hello, Sorry if I don't understand what you need but I have no experience in profiling Mono. What is the sample program that you need? Sorry but I really didn't understand what exactly you need. The profiler today only runs when the program exists successfully, so we need a shorter test case, something that will not take one hour to build, but something that will take, say, a minute to build. Once we have something that takes a minute to build (or even 10 seconds instead of instantaneous builds) we can start looking where the memory went. My take is that probably building a chunk of the VB runtime is probably good enough for this. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Hello, Are you using latest svn for vbnc? A few optimization was committed this week so it should be faster. If it is running out of memory though I think there might some other problem optimizations won't resolve. Rolf On Sun, 29 Oct 2006 19:21:07 +0100, Kornél Pál [EMAIL PROTECTED] wrote: Hi, Using the patch in http://lists.ximian.com/pipermail/mono-devel-list/2006-October/021093.html no exception ocurred in vbnc but I wasn't able to finish the resolve phase because it runs out of memory. The machine I used has 1 GB RAM and is running Windows XP. And I think such a machine should be able to run a VB compiler. Note that running the same binary on MS.NET is much faster and requires much less memory. If you have any idea making VBNC's footprint smaller please let me know. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] VBNC uses too much CPU and RAM on Mono
Hi, Using the patch in http://lists.ximian.com/pipermail/mono-devel-list/2006-October/021093.html no exception ocurred in vbnc but I wasn't able to finish the resolve phase because it runs out of memory. The machine I used has 1 GB RAM and is running Windows XP. And I think such a machine should be able to run a VB compiler. Note that running the same binary on MS.NET is much faster and requires much less memory. If you have any idea making VBNC's footprint smaller please let me know. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Hi, I was using SVN HEAD. Please try the previously referenced patch, maybe you will be able to find out something more. The compiler don't seem to have endless recursions or loops but I may be wrong. Other than this problem I have no other idea, because it's running, but is slow and eats memory. Kornél - Original Message - From: Rolf Bjarne Kvinge [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com Sent: Sunday, October 29, 2006 7:37 PM Subject: Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono Hello, Are you using latest svn for vbnc? A few optimization was committed this week so it should be faster. If it is running out of memory though I think there might some other problem optimizations won't resolve. Rolf On Sun, 29 Oct 2006 19:21:07 +0100, Kornél Pál [EMAIL PROTECTED] wrote: Hi, Using the patch in http://lists.ximian.com/pipermail/mono-devel-list/2006-October/021093.html no exception ocurred in vbnc but I wasn't able to finish the resolve phase because it runs out of memory. The machine I used has 1 GB RAM and is running Windows XP. And I think such a machine should be able to run a VB compiler. Note that running the same binary on MS.NET is much faster and requires much less memory. If you have any idea making VBNC's footprint smaller please let me know. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Hey, Even after the patches I suggested to Rolf, VBNC had a heap size of ~100mb on MSFT. I'm a bit suprised Mono is having so much trouble. It's quite possible this is a GC issue. The compiler stores a very large linked list of all tokens in the program. With a non-generational gc, we may be having very bad performance from walking the heap so much. You might try aborting before the resolve phase, to see if you can --profile before that point on Mono. Also, it's worth using profilers on MSFT's runtime (most commercial ones have demos, that's always worked for me). Sadly, I'm not going to have time to take a look at this for quite a while. -b I was using SVN HEAD. Please try the previously referenced patch, maybe you will be able to find out something more. The compiler don't seem to have endless recursions or loops but I may be wrong. Other than this problem I have no other idea, because it's running, but is slow and eats memory. Kornél - Original Message - From: Rolf Bjarne Kvinge [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com Sent: Sunday, October 29, 2006 7:37 PM Subject: Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono Hello, Are you using latest svn for vbnc? A few optimization was committed this week so it should be faster. If it is running out of memory though I think there might some other problem optimizations won't resolve. Rolf On Sun, 29 Oct 2006 19:21:07 +0100, Kornél Pál [EMAIL PROTECTED] wrote: Hi, Using the patch in http://lists.ximian.com/pipermail/mono-devel-list/2006-October/021093.html no exception ocurred in vbnc but I wasn't able to finish the resolve phase because it runs out of memory. The machine I used has 1 GB RAM and is running Windows XP. And I think such a machine should be able to run a VB compiler. Note that running the same binary on MS.NET is much faster and requires much less memory. If you have any idea making VBNC's footprint smaller please let me know. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono
Hi, Thanks for your tip regarding the GC, I've added a new thread to the compiler that does: Do Thread.Sleep(1) mainThread.Suspend() GC.Collect() GC.WaitForPendingFinalizers() ' ... 10 times mainThread.Resume() Loop And it Finished Resolve and is Starting Define. But then I got the exception: Unhandled Exception: System.TypeLoadException: A type load exception has occurred. at System.Type.MakeGenericType (System.Type[] types) [0x0005a] in ...\mcs\class\corlib\System\Type.cs:1159 at vbnc.GenericTypeDescriptor.get_TypeInReflection () [0x000ba] in ...\vbnc\vbnc\source\Descriptors\GenericTypeDescriptor.vb:134 I'll probably be able to fix that one as well, but my very-very big problem is that vbnc is so undarebly slow on Mono that it's quite impossible to wait for the compiler to reach again the stage where it's failing. If the results of previous stages could be serialized it could save a lot of time and the actual stage could be debugged. Any help on speeding up vbnc is welcome. Kornél - Original Message - From: Ben Maurer [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED] Cc: mono-devel-list@lists.ximian.com Sent: Sunday, October 29, 2006 8:44 PM Subject: Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono Hey, Even after the patches I suggested to Rolf, VBNC had a heap size of ~100mb on MSFT. I'm a bit suprised Mono is having so much trouble. It's quite possible this is a GC issue. The compiler stores a very large linked list of all tokens in the program. With a non-generational gc, we may be having very bad performance from walking the heap so much. You might try aborting before the resolve phase, to see if you can --profile before that point on Mono. Also, it's worth using profilers on MSFT's runtime (most commercial ones have demos, that's always worked for me). Sadly, I'm not going to have time to take a look at this for quite a while. -b I was using SVN HEAD. Please try the previously referenced patch, maybe you will be able to find out something more. The compiler don't seem to have endless recursions or loops but I may be wrong. Other than this problem I have no other idea, because it's running, but is slow and eats memory. Kornél - Original Message - From: Rolf Bjarne Kvinge [EMAIL PROTECTED] To: Kornél Pál [EMAIL PROTECTED]; mono-devel-list@lists.ximian.com Sent: Sunday, October 29, 2006 7:37 PM Subject: Re: [Mono-dev] VBNC uses too much CPU and RAM on Mono Hello, Are you using latest svn for vbnc? A few optimization was committed this week so it should be faster. If it is running out of memory though I think there might some other problem optimizations won't resolve. Rolf On Sun, 29 Oct 2006 19:21:07 +0100, Kornél Pál [EMAIL PROTECTED] wrote: Hi, Using the patch in http://lists.ximian.com/pipermail/mono-devel-list/2006-October/021093.html no exception ocurred in vbnc but I wasn't able to finish the resolve phase because it runs out of memory. The machine I used has 1 GB RAM and is running Windows XP. And I think such a machine should be able to run a VB compiler. Note that running the same binary on MS.NET is much faster and requires much less memory. If you have any idea making VBNC's footprint smaller please let me know. Kornél ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
