Re: [Mono-dev] Internal-Call
Dexter Yao wrote: > > Is there a another better way to call from C#( managed code ) by passing the > pointer( IntPtr in C# ) of one C++ object and invoke its method? ( like the > Lua does ) > Looking forward to your reply. There is no other way to invoke arbitrary C++ methods, but you could design your classes (or write wrappers) for COM interop: http://blog.worldofcoding.com/2009/08/binding-c-apis.html Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Internal-Call
On Dec 9, 2009, at 4:35 AM, Robert Jordan wrote: > Dexter Yao wrote: >> >> Is there a another better way to call from C#( managed code ) by >> passing the >> pointer( IntPtr in C# ) of one C++ object and invoke its method? >> ( like the >> Lua does ) >> Looking forward to your reply. > > There is no other way to invoke arbitrary C++ methods, but you > could design your classes (or write wrappers) for COM interop: > > http://blog.worldofcoding.com/2009/08/binding-c-apis.html > > Robert > Please look into SWIG as well. It can Automatically generate wrappers from c++ to csharp Raj > ___ > 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] How to improve Dataset Performance
For sure I can pass a test case, is better that I file a bug report?
I think that Mono team already knows where datasets are slower than
MS.Net and maybe can suggest me some "best practice".
Btw with the code provided below with MS.Net on a standard developer
machine and Mono on a bi-processor testing machine (with 2GB of ram):
1000 rows
MS.Net: 130ms
Mono 2.4.3: 1.2s
Mono 2.0.1: 3.5s
10.000 rows
MS.Net: less than a second
Mono 2.4.3: 114s
Mono 2.0.1: 361s
I have tables with more than 50.000 rows...I don't know how much it
takes to perform the elaboration. RowFilter speed up only if applied
on small rowsets.
The problem is in the .Select method, removing those lines the
elaboration is quicker in Mono. Testing machines are not with the
same resources but the difference is too much to think to an hardware
difference.
Here is the code...
DataSet ds1 = new DataSet();
ds1.Tables.Add();
ds1.Tables[0].Columns.Add("COL1", typeof(string));
ds1.Tables[0].Columns.Add("COL2", typeof(int));
ds1.Tables[0].Columns.Add("COL3", typeof(bool));
for (int i = 0; i < 1; i++) {
ds1.Tables[0].Rows.Add(new object[] { "test", i, true });
}
DataSet ds2 = new DataSet();
ds2.Tables.Add();
ds2.Tables[0].Columns.Add("COL1", typeof(string));
ds2.Tables[0].Columns.Add("COL2", typeof(int));
ds2.Tables[0].Columns.Add("COL3", typeof(bool));
for (int i = 0; i < 1; i++) {
ds2.Tables[0].Rows.Add(new object[] { "test", i, true });
}
DataSet ds3 = new DataSet();
ds3.Tables.Add();
ds3.Tables[0].Columns.Add("COL1", typeof(string));
ds3.Tables[0].Columns.Add("COL2", typeof(int));
ds3.Tables[0].Columns.Add("COL3", typeof(bool));
for (int i = 0; i < 1; i++) {
ds3.Tables[0].Rows.Add(new object[] { "test", i, true });
}
int idx=0;
foreach (DataRow dr in ds1.Tables[0].Rows) {
DataRow[] dr2 = ds2.Tables[0].Select("COL2=" + idx);
DataRow[] dr3 = ds3.Tables[0].Select("COL2=" + idx);
idx++;
}
At 21.59 02/12/2009, Nagappan Alagappan wrote:
Hello,
Do you have a test case to reproduce this issue, which you could
share with the Mono team ?
Thanks
Nagappan
On Wed, Dec 2, 2009 at 4:05 AM, APS
<dev.ma...@apsystems.it> wrote:
Hi,
I'm testing some old elaboration that cycles on a large datatable and
for every rows makes several selections on separated datatables.
This elaboration is really slow on mono and fast on
MS.NET, let say
400secs vs 4 secs.
It seems that last rows are slower that first rows.
I made some test on datasets scroll and I saw that mono performance
is better than MS.NET so the delay is due to inner selections.
I changed datatable.select in defaultview.sort and I gained 200secs,
still too slow.
Now I've identified some datatable.compute as the main delay source.
I'll try to change them using Linq but the question is: there's some
known performance problem in dataset heavy usage, there's some best
pratice that you can suggest to speed up elaborations?
Thanks in advance.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Linux Desktop (GUI Application) Testing Project -
http://ldtp.freedesktop.org
http://nagappanal.blogspot.com
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da
Re: [Mono-dev] Internal-Call
Thank both of you for helping me a lot. -- View this message in context: http://old.nabble.com/Internal-Call-tp26691444p26710312.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Reflection.Assembly::Load Performance?
2009/12/1 Zoltan Varga
> On Tue, Dec 1, 2009 at 6:02 PM, Babbage Linden wrote:
>
>> Hi all,
>>
>> I'm currently investigating a performance problem which is causing complex
>> objects in Second Life containing many scripts to take a long time to load.
>>
>> We embed Mono in the Second Life simulator, so I turned on the profiler
>> before initialising the runtime:
>>
>> mono_profiler_load("default:stat");
>> mono_jit_init("root domain");
>> mono_internal_call_init();
>>
>> After shutting down the simulator, the profiler reported the slow method
>> as being System.Reflection.Assembly::Load(byte[]), with each call taking
>> 19.961ms:
>>
>> Time(ms) Count P/call(ms) Method name
>>
>> 4052.135 203 19.961 System.Reflection.Assembly::Load(byte[])
>> Callers (with count) that contribute at least for 1%:
>> 102 50 % LindenLab.SecondLife.Script::.ctor(string,byte[],long&)
>> 101 49 % LindenLab.SecondLife.Script::Deserialize(byte[],byte[])
>>
>> Does this seem right? We're just passing an assembly as bytes to Mono and
>> asking it to turn it in to an assembly, 19ms seems like a long time to do
>> that.
>>
>> Are there any faster ways we could do this? In the example above an object
>> with 200 scripts in it is taking 4s to load, which is much faster than with
>> an LSL script.
>>
>>
> I can't reproduce this, most of the work happens in native code, could you
> try running under
> valgrind --tool=callgrind, that will profile the runtime code.
>
OK, I have a (15MB) callgrind.out file, what's the best way for me to get it
to you?
Cheers,
Jim
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Reflection.Assembly::Load Performance?
2009/12/1 Zoltan Varga
> Hi,
>
> It is possible that you are using AppDomain.AssemblyLoad which is called
> every time an
> assembly is loaded ? Or a profiler callback ?
>
>
The code I'm using for loading is:
public Script(string class_name, byte[] class_data,
ref long event_handlers)
{
Init();
Assembly assembly = Assembly.Load(class_data);
foreach (Type NewType in assembly.GetTypes())
{
if (NewType.IsSubclassOf(typeof(UserScript)))
{
UserScript userScript =
(UserScript)assembly.CreateInstance(
NewType.ToString());
SetUser(userScript, ref event_handlers);
return;
}
}
}
It's the Assembly.Load(class_data) call that is taking the time.
Cheers,
Jim
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] How to improve Dataset Performance
2009/12/9 APS :
> For sure I can pass a test case, is better that I file a bug report? I think
> that Mono team already knows where datasets are slower than MS.Net and maybe
> can suggest me some "best practice".
> Btw with the code provided below with MS.Net on a standard developer machine
> and Mono on a bi-processor testing machine (with 2GB of ram):
>
> 1000 rows
> MS.Net: 130ms
> Mono 2.4.3: 1.2s
> Mono 2.0.1: 3.5s
>
> 10.000 rows
> MS.Net: less than a second
> Mono 2.4.3: 114s
> Mono 2.0.1: 361s
So when the data size increase by a factor of 10, on ms.net the time
taken also seem to increase by a factor of 10, but on mono by a factor
of 100. Seems like an an O(N) versus an O(N²) algorithm.
The code below contains a loop and you claim the Select part is taking
the most time. If that is true, it seems to indicate that ms.net
Select() for this case is O(1) but mono's O(N), with N being the
number of rows in the table.
/Oskar
> I have tables with more than 50.000 rows...I don't know how much it takes to
> perform the elaboration. RowFilter speed up only if applied on small
> rowsets.
> The problem is in the .Select method, removing those lines the elaboration
> is quicker in Mono. Testing machines are not with the same resources but the
> difference is too much to think to an hardware difference.
> Here is the code...
>
> DataSet ds1 = new DataSet();
> ds1.Tables.Add();
> ds1.Tables[0].Columns.Add("COL1", typeof(string));
> ds1.Tables[0].Columns.Add("COL2", typeof(int));
> ds1.Tables[0].Columns.Add("COL3", typeof(bool));
> for (int i = 0; i < 1; i++) {
> ds1.Tables[0].Rows.Add(new object[] { "test", i, true });
> }
> DataSet ds2 = new DataSet();
> ds2.Tables.Add();
> ds2.Tables[0].Columns.Add("COL1", typeof(string));
> ds2.Tables[0].Columns.Add("COL2", typeof(int));
> ds2.Tables[0].Columns.Add("COL3", typeof(bool));
> for (int i = 0; i < 1; i++) {
> ds2.Tables[0].Rows.Add(new object[] { "test", i, true });
> }
> DataSet ds3 = new DataSet();
> ds3.Tables.Add();
> ds3.Tables[0].Columns.Add("COL1", typeof(string));
> ds3.Tables[0].Columns.Add("COL2", typeof(int));
> ds3.Tables[0].Columns.Add("COL3", typeof(bool));
> for (int i = 0; i < 1; i++) {
> ds3.Tables[0].Rows.Add(new object[] { "test", i, true });
> }
> int idx=0;
> foreach (DataRow dr in ds1.Tables[0].Rows) {
> DataRow[] dr2 = ds2.Tables[0].Select("COL2=" + idx);
> DataRow[] dr3 = ds3.Tables[0].Select("COL2=" + idx);
>
> idx++;
> }
>
>
>
>
> At 21.59 02/12/2009, Nagappan Alagappan wrote:
>
> Hello,
>
> Do you have a test case to reproduce this issue, which you could share with
> the Mono team ?
>
> Thanks
> Nagappan
>
> On Wed, Dec 2, 2009 at 4:05 AM, APS wrote:
> Hi,
>
> I'm testing some old elaboration that cycles on a large datatable and
> for every rows makes several selections on separated datatables.
> This elaboration is really slow on mono and fast on MS.NET, let say
> 400secs vs 4 secs.
> It seems that last rows are slower that first rows.
> I made some test on datasets scroll and I saw that mono performance
> is better than MS.NET so the delay is due to inner selections.
> I changed datatable.select in defaultview.sort and I gained 200secs,
> still too slow.
> Now I've identified some datatable.compute as the main delay source.
> I'll try to change them using Linq but the question is: there's some
> known performance problem in dataset heavy usage, there's some best
> pratice that you can suggest to speed up elaborations?
> Thanks in advance.
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>
> --
> Linux Desktop (GUI Application) Testing Project -
> http://ldtp.freedesktop.org
> http://nagappanal.blogspot.com
>
> --
> Il messaggio e' stato analizzato alla ricerca di virus o
> contenuti pericolosi da MailScanner, ed e'
> risultato non infetto.
>
> ___
> 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] System.Reflection.Assembly::Load Performance?
On Wed, Dec 9, 2009 at 12:00 PM, Babbage Linden wrote:
>
> The code I'm using for loading is:
>
> public Script(string class_name, byte[] class_data,
> ref long event_handlers)
> {
> Init();
> Assembly assembly = Assembly.Load(class_data);
> foreach (Type NewType in assembly.GetTypes())
> {
> if (NewType.IsSubclassOf(typeof(UserScript)))
> {
> UserScript userScript =
> (UserScript)assembly.CreateInstance(
> NewType.ToString());
>
> SetUser(userScript, ref event_handlers);
> return;
> }
> }
> }
>
>
This loop will consume a lot of resources as the runtime have to decode and
load all types in the assembly before returning it.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] SIGSEGV when using WeakReferences in multi-threaded application
Hi, > Sorry about that. I tried debugging it back then, but couldn't find > out the cause of the > problem, it seemed like memory corruption inside the GC data structures. thanks for your comment on that. Although we added a workaround for that particular problem in our software, this cannot be the final solution. Our software works dramatically slower with that workaround. If there is something wrong with the GC shouldn't that be fixed sometime? As we got some more issues with segfaults of the mono runtime, we fear that those may occur due to the same problem weak references in our multi-threaded application. -- regards Daniel Weuthen ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Reflection.Assembly::Load Performance?
On Wed, Dec 9, 2009 at 3:38 PM, Rodrigo Kumpera wrote:
>
>
> On Wed, Dec 9, 2009 at 12:00 PM, Babbage Linden
> wrote:
>>
>> The code I'm using for loading is:
>>
>> public Script(string class_name, byte[] class_data,
>> ref long event_handlers)
>> {
>> Init();
>> Assembly assembly = Assembly.Load(class_data);
>> foreach (Type NewType in assembly.GetTypes())
>> {
>> if (NewType.IsSubclassOf(typeof(UserScript)))
>> {
>> UserScript userScript =
>> (UserScript)assembly.CreateInstance(
>> NewType.ToString());
>>
>> SetUser(userScript, ref event_handlers);
>> return;
>> }
>> }
>> }
>>
>
> This loop will consume a lot of resources as the runtime have to decode and
> load all types in the assembly before returning it.
>
This foreach loop is a common pattern for loading subclasses/plugins
from an assembly, is there a better pattern for this?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Reflection.Assembly::Load Performance?
On Wed, 2009-12-09 at 16:20 +0100, Leszek Ciesielski wrote:
> This foreach loop is a common pattern for loading subclasses/plugins
> from an assembly, is there a better pattern for this?
Yes: assembly-level attributes.
http://weblogs.asp.net/justin_rogers/articles/61042.aspx
See the "1. Assembly Attribute Marking" section.
In short, you'd add a new attribute:
[AttributeUsage(AttributeTargets.Assembly, AllowMultiple=true)]
class PluginAttribute : Attribute {
public PluginAttribute (Type type) {this.Type = type;}
public Type Type {get; private set;}
}
Then specify this attribute at the assembly level:
[assembly:Plugin (typeof(Plugin1))]
[assembly:Plugin (typeof(Plugin2))]
// ...
Then query the assembly for all the PluginAttributes:
Assembly a = ...;
PluginAttribute[] plugins =
(PluginAttribute[]) a.GetCustomAttributes (
typeof(PluginAttribute), true);
foreach (var plugin in plugins)
// plugin.Type is the type to use as a plugin
This can be significantly faster than using Assembly.GetTypes(), as only
the types which are listed in [assembly:Plugin] attributes actually need
to be loaded, which can significantly decrease the amount of memory
consumed (depending on the number of types in the assembly).
- Jon
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Reflection.Assembly::Load Performance?
On 09.12.2009 16:20, Leszek Ciesielski wrote: >> This loop will consume a lot of resources as the runtime have to decode and >> load all types in the assembly before returning it. >> > This foreach loop is a common pattern for loading subclasses/plugins > from an assembly, is there a better pattern for this? Assembly.GetExportedTypes() should be used instead. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Announcing the release of Mono 2.4.3
Yesterday we released Mono 2.4.3. This release contains a large number of bug fixes, including fixes for security bugs. The release notes are here: http://go-mono.com/archive/2.4.3 and downloads are available here: http://go-mono.com/mono-downloads/ We have not released LiveCD or Appliance images because we are working toward a 2.6 release in the near future. Thanks to all those who contributed to this release! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing the release of Mono 2.4.3
The release notes lists the following issue as fixed: 467418 (https://bugzilla.novell.com/show_bug.cgi?id=467418) - ListView in VirtualMode uses too much memory and is slow But the bug report is still marked as NEW and there is no comment indicating that a fix has been checked in. What is the interpretation of this? /Oskar 2009/12/9 Andrew Jorgensen : > Yesterday we released Mono 2.4.3. This release contains a large number > of bug fixes, including fixes for security bugs. > > The release notes are here: > http://go-mono.com/archive/2.4.3 > > and downloads are available here: > http://go-mono.com/mono-downloads/ > > We have not released LiveCD or Appliance images because we are working > toward a 2.6 release in the near future. > > Thanks to all those who contributed to this release! > > > > ___ > 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] Announcing the release of Mono 2.4.3
There were two commits to SVN with regards to this bug so it looks like it was accidently not closed. CC'ing the guy who committed those fixes as he'd be the one to know whether it should be closed or not. Alan. On Wed, Dec 9, 2009 at 10:41 PM, Oskar Berggren wrote: > The release notes lists the following issue as fixed: > 467418 (https://bugzilla.novell.com/show_bug.cgi?id=467418) - ListView > in VirtualMode uses too much memory and is slow > > But the bug report is still marked as NEW and there is no comment > indicating that a fix has been checked in. What is the interpretation > of this? > > /Oskar > > > > 2009/12/9 Andrew Jorgensen : > > Yesterday we released Mono 2.4.3. This release contains a large number > > of bug fixes, including fixes for security bugs. > > > > The release notes are here: > >http://go-mono.com/archive/2.4.3 > > > > and downloads are available here: > >http://go-mono.com/mono-downloads/ > > > > We have not released LiveCD or Appliance images because we are working > > toward a 2.6 release in the near future. > > > > Thanks to all those who contributed to this release! > > > > > > > > ___ > > 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
Re: [Mono-dev] Announcing the release of Mono 2.4.3
The release notes say that debugging works on OSX now when logged in as root. I just installed mono 2.4.3 and the latest monodevelop 2.2 rc on OSX 10.6.2. I enabled the root account, then logged in as root. I then created a console app in monodevelop and put in breakpoints. The menu under "run" has the "debug" option grayed out. What else do I need to do to enable this? thanks, Kris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing the release of Mono 2.4.3
On Wed, Dec 9, 2009 at 10:40 PM, Kris Ray wrote: > > The release notes say that debugging works on OSX now when logged in as root. > > I just installed mono 2.4.3 and the latest monodevelop 2.2 rc on OSX 10.6.2. > > I enabled the root account, then logged in as root. > > I then created a console app in monodevelop and put in breakpoints. > > The menu under "run" has the "debug" option grayed out. What else do I need > to do to enable this? This appears to have been an error in th 2.4.3 release notes. AFAIK mdb only works in Mono 2.6. Even then, Monodevelop for MacOS does not include the mdb addin. I suggest waiting for Mono 2.6 which should be out soon. It has the new "soft" debugger built in, and MonoDevelop 2.2 also has built-in support for the soft debugger. SDB is much more portable, and works very well on MacOS -- Michael Hutchinson http://mjhutchinson.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Announcing the release of Mono 2.4.3
Kris, Apologies, this was an error in the release notes. The first release on OSX with support for the debugger will be 2.6 Geoff On 2009-12-09, at 10:40 PM, Kris Ray wrote: > > The release notes say that debugging works on OSX now when logged in as root. > > I just installed mono 2.4.3 and the latest monodevelop 2.2 rc on OSX 10.6.2. > > I enabled the root account, then logged in as root. > > I then created a console app in monodevelop and put in breakpoints. > > The menu under "run" has the "debug" option grayed out. What else do I need > to do to enable this? > > thanks, > Kris > ___ > 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] Announcing the release of Mono 2.4.3
It was indeed fixed. Sorry, I forgot to close that one. Carlos. 2009/12/9 Oskar Berggren > The release notes lists the following issue as fixed: > 467418 (https://bugzilla.novell.com/show_bug.cgi?id=467418) - ListView > in VirtualMode uses too much memory and is slow > > But the bug report is still marked as NEW and there is no comment > indicating that a fix has been checked in. What is the interpretation > of this? > > /Oskar > > > > 2009/12/9 Andrew Jorgensen : > > Yesterday we released Mono 2.4.3. This release contains a large number > > of bug fixes, including fixes for security bugs. > > > > The release notes are here: > >http://go-mono.com/archive/2.4.3 > > > > and downloads are available here: > >http://go-mono.com/mono-downloads/ > > > > We have not released LiveCD or Appliance images because we are working > > toward a 2.6 release in the near future. > > > > Thanks to all those who contributed to this release! > > > > > > > > ___ > > 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
