Bug 13831 - Mono block execution unproportional to individual execution
Summary: Mono block execution unproportional to individual execution
Alias: None
Product: Runtime
Classification: Mono
Component: GC ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2013-08-07 16:34 UTC by Alexandre Faria
Modified: 2018-01-24 18:00 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Alexandre Faria 2013-08-07 16:34:08 UTC
When I execute tasks one at a time (multiple sequential processes), they are a lot faster than executing all, one after the other in a single execution (unique process single thread).

In a real example, a task that takes about 20m/30m alone jumps to 1h30m or more in the middle of others.
This happens in memory usage situations under 10%.

I tried with many examples, this one was the faster to show similar traits I found so far, although the difference is a lot smaller, but I hope its representative.

On the 4k execution the overhead comparative to 1k is more than 50%.

Example Execution:
real	 1m54.990s
user	 1m54.044s
sys	 0m1.056s

real	20m40.392s
user	20m29.788s
sys	0m12.484s

real	48m44.221s
user	48m25.624s
sys	0m21.388s

real	134m53.715s
user	134m15.960s
sys	0m39.944s

Sample Code:
using System;

public class A
        public static void Main(string[] args)
                uint count = uint.Parse(args[0]);
                for(int i=0; i<count; i++)
                        System.Console.WriteLine("\n\nIteration " + i);
                        AppDomain ad = AppDomain.CreateDomain("ChildDomain");

Mono JIT compiler version 3.3.0 (master/b213fac Qua Ago  7 10:19:08 WEST 2013)
	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          yes(3.3svn-mono)
	GC:            sgen
Comment 1 Alexandre Faria 2013-08-21 13:04:46 UTC
After some additional testing, I realized the problem I have might be related to open files.

The real scenario is basically a CI testing.

If I pre-build, then the tests execution take about 28m.
The pre-build takes about 8m.

But if I don't pre-build, the tests execution take about 1h25m.
(Some additional extra 5 minutes if I execute the other components tests before)

As the build process is mostly file and memory heavy, I was guessing it might be a memory allocation issue.

But I was unable to reproduce it, the best I got so far was that sample, with an overhead of more than 50%, but it might not be a good one, as very few app domains are being used, at most 10 I guess.

I'm suspecting something related to the files, as it takes more than 3x the time, 200% of overhead.

Is there anything I can do to pin down the exact source of the problem or this is some kind of expected behaviour?
Comment 2 Rodrigo Kumpera 2017-10-14 00:11:17 UTC
Thank you for your report!

It appears you are running a very old version of Mono. Could you please try to update to any recent version and try to reproduce the issue again.

If the issue still persists please include the version information and change the bug status to NEW.
Comment 3 Ludovic Henry 2018-01-24 18:00:47 UTC
Please provide information requested in previous comment to reopen. Thank you.