Performance: interop Object vs 'native' cside code

nXqd · 2012-05-24

Hi everyone,

Making connector from nav to another webservice from cside takes a lot of codes and it's hard to maintain and write clean code compared to writing the same function in .net. This is one of examples.
This aims at small and mid companies. To me, maintainable and easy to understand code comes first then performance follows later even though I also care a lot about performance.

My question is : what if a .net assembly performs better or worse then it's c/side code equivalent?

I'm on my way to be MVP ... ( lolz )

Cheers,

deV.ch · 2012-05-24

Well.. is it just me or is there no question in your post ?

Do you want to discuss if a .net assembly performs better or worse then it's c/side code equivalent?

If so, then i vote for the assembly to be more performant, since your c/al code is converted to .net anyway... so i guess you can write cleaner and more performatn code by doing your work in .net directly. Even if it's not more performant i bet its performance is not worse then with c/al so the huge advantage of the .net environment in case of consuming webservices is definitly the way to go!

nXqd · 2012-05-24

deV.ch wrote:

Well.. is it just me or is there no question in your post ?
Do you want to discuss if a .net assembly performs better or worse then it's c/side code equivalent?

If so, then i vote for the assembly to be more performant, since your c/al code is converted to .net anyway... so i guess you can write cleaner and more performatn code by doing your work in .net directly. Even if it's not more performant i bet its performance is not worse then with c/al so the huge advantage of the .net environment in case of consuming webservices is definitly the way to go!

Thanks, I thought the title provides enough information. It's my question exactly is what if a .net assembly performs better or worse then it's c/side code equivalent?

I've just heard this from my boss and I still don't understand why a legend language is translated to a modern one :P Do you have any good information about this ?

Thanks

Sog · 2012-05-24

The legend code still exists because when Microsoft announced they wanted to change C/AL to C# in 2009 the partners started to protest saying that NAV developers aren't C# developers. (source Microsoft Belgium employee for NAV)
That's why they postponed it to 2013 (in the roadmap presented at the same meeting). Although I haven't seen the new NAV yet. NAV is gradually going to C#, letting the developers use more and more C# for a smoother transfer.

deV.ch · 2012-05-24

And as much is i love c#, but for every day nav programming it would just be too much. Far Simple dataprocessing c/al is perfect, and with the interop feature you can break out of the chains when you have to.

kriki · 2012-05-24

And having all those hotshot C# programmers messing around in C/AL functionality is very dangerous.
You can take the best C# programmer in the world and let him loose in NAV and he will probably destroy NAV if he doesn't know NAV well and how to behave in NAV.

DenSter · 2012-05-24

Sog wrote:

NAV is gradually going to C#, letting the developers use more and more C# for a smoother transfer.

This is absolutely false information. NAV 2013 still works with C/AL, and there are no formal plans for moving to C#.

DenSter · 2012-05-24

Sog wrote:

The legend code still exists because when Microsoft announced they wanted to change C/AL to C# in 2009 the partners started to protest saying that NAV developers aren't C# developers. (source Microsoft Belgium employee for NAV)

Actually this is a very common misconception. In some of the early beta builds of NAV 2009, creating the managed code was a two-step task, where you had to create the .cs files as flat text files and then run those through a compiler to assemble the managed code. This two-step approach was never intended to be part of the product, in fact the plan had always been to automate those steps as part of compiling objects from the object designer. However, it was shown in a number of presentations, and wildly misunderstood by audiences, and through the rumor mill people got very upset about that.

There was never an announcement that NAV was going to C#.

davmac1 · 2012-05-24

You sure it was not intended as a "trial balloon"?

kine · 2012-05-24

You can use the assembly not just because better performance, but e.g. because better IP protection. Of course, there are some cons like distribution of the assembly. But all could be solved somehow...

deV.ch · 2012-05-25

Yeah kine i thought about that just when i read the inital post, that con could be solved by dinamicaly creating the assembly (and invoking methods) from a .cs file that you store in your database, that way you wouldn't have to distribute the assembly. But i have to admit i haven't tested it (yet)

Anybody already done it?

nXqd · 2012-05-25

kine wrote:

You can use the assembly not just because better performance, but e.g. because better IP protection. Of course, there are some cons like distribution of the assembly. But all could be solved somehow...

Thanks for this useful information. I'm new to NAV, just come out of school and work for a NAV Partner. I work mostly on C# and java in school, so that business terms in NAV somehow is confused for me. So I'm finding a good book to learn about NAV in business mind instead of coder. It'd be great if anyone here can suggest me one

// Sorry for off-topic

Have a nice day !

Sog · 2012-05-25

DenSter wrote:

Sog wrote:

NAV is gradually going to C#, letting the developers use more and more C# for a smoother transfer.

This is absolutely false information. NAV 2013 still works with C/AL, and there are no formal plans for moving to C#.

If i find that powerpoint with that roadmap on, I can prove I was misinformed by MS

deV.ch · 2012-05-25

If anybody is interested i tried to dynamicly invoke csharp code through interop so you don't necessarily need to create an assembly for your dotnet code (therefore don't need to bother about distribution).
It's a smiple example but shows the idea behind it.

Here is the code:

OnRun()

ScriptBT.ADDTEXT('namespace Foo');
ScriptBT.ADDTEXT('{');
ScriptBT.ADDTEXT('    public class Bar');
ScriptBT.ADDTEXT('    {');
ScriptBT.ADDTEXT('        public string SayHello()');
ScriptBT.ADDTEXT('        {');
ScriptBT.ADDTEXT('            return("Hello World");');
ScriptBT.ADDTEXT('        }');
ScriptBT.ADDTEXT('    }');
ScriptBT.ADDTEXT('}');


ScriptBT.GETSUBTEXT(ScriptText,1);
InvokeCSharpScript(ScriptText);

InvokeCSharpScript(_Script : Text)
provider := provider.CSharpCodeProvider();

CompilerParams := CompilerParams.CompilerParameters();
CompilerParams.GenerateInMemory(TRUE);
CompilerParams.GenerateExecutable(FALSE);


// Create Array for Parameter
"Array" := "Array".CreateInstance(GETDOTNETTYPE(string),1);
"Array".SetValue(_Script,0);

result := provider.CompileAssemblyFromSource(CompilerParams, "Array");

IF result.Errors.Count <> 0 THEN
  ERROR('Compiler Errors in Script');

// Initialize Emtpy array (Simulate null parameter)
"Array" := "Array".CreateInstance(GETDOTNETTYPE(object),0);

object := result.CompiledAssembly.CreateInstance('Foo.Bar');

MethodInfo := object.GetType.GetMethod('SayHello');
NavVariant := MethodInfo.Invoke(object, "Array");


MESSAGE('%1', NavVariant);

Variables:
Name DataType Subtype Length
provider DotNet Microsoft.CSharp.CSharpCodeProvider.'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
CompilerParams DotNet System.CodeDom.Compiler.CompilerParameters.'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
result DotNet System.CodeDom.Compiler.CompilerResults.'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
object DotNet System.Object.'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
MethodInfo DotNet System.Reflection.MethodInfo.'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
Array DotNet System.Array.'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
string DotNet System.String.'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
MethodResult DotNet System.Object.'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
NavVariant Variant

nXqd · 2012-05-25

deV.ch wrote:
If anybody is interested i tried to dynamicly invoke csharp code through interop so you don't necessarily need to create an assembly for your dotnet code (therefore don't need to bother about distribution).
It's a smiple example but shows the idea behind it.

Here is the code:
OnRun()

ScriptBT.ADDTEXT('namespace Foo');
ScriptBT.ADDTEXT('{');
ScriptBT.ADDTEXT('    public class Bar');
ScriptBT.ADDTEXT('    {');
ScriptBT.ADDTEXT('        public string SayHello()');
ScriptBT.ADDTEXT('        {');
ScriptBT.ADDTEXT('            return("Hello World");');
ScriptBT.ADDTEXT('        }');
ScriptBT.ADDTEXT('    }');
ScriptBT.ADDTEXT('}');


ScriptBT.GETSUBTEXT(ScriptText,1);
InvokeCSharpScript(ScriptText);

InvokeCSharpScript(_Script : Text)
provider := provider.CSharpCodeProvider();

CompilerParams := CompilerParams.CompilerParameters();
CompilerParams.GenerateInMemory(TRUE);
CompilerParams.GenerateExecutable(FALSE);


// Create Array for Parameter
"Array" := "Array".CreateInstance(GETDOTNETTYPE(string),1);
"Array".SetValue(_Script,0);

result := provider.CompileAssemblyFromSource(CompilerParams, "Array");

IF result.Errors.Count <> 0 THEN
  ERROR('Compiler Errors in Script');

// Initialize Emtpy array (Simulate null parameter)
"Array" := "Array".CreateInstance(GETDOTNETTYPE(object),0);

object := result.CompiledAssembly.CreateInstance('Foo.Bar');

MethodInfo := object.GetType.GetMethod('SayHello');
NavVariant := MethodInfo.Invoke(object, "Array");


MESSAGE('%1', NavVariant);
Variables:
Name DataType Subtype Length
provider DotNet Microsoft.CSharp.CSharpCodeProvider.'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
CompilerParams DotNet System.CodeDom.Compiler.CompilerParameters.'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
result DotNet System.CodeDom.Compiler.CompilerResults.'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
object DotNet System.Object.'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
MethodInfo DotNet System.Reflection.MethodInfo.'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
Array DotNet System.Array.'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
string DotNet System.String.'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
MethodResult DotNet System.Object.'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
NavVariant Variant

Interesting !
First time, I'm thinking about writing cleaner and easy to use code. But now, it's getting more interesting with this complex one \:D/
Thanks

kine · 2012-05-26

Of course, in this way, the IP will not be protected, and of course, the performance will go down because the compilation... but very nice idea which could be used to different things... :thumbsup:

deV.ch · 2012-05-26

Well that was just a proof of concept

But to go a bit deeper about your points:
-I don't know exactly what you mean by IP protection.
-Performance could be saved by making a single instance codeunit and compile the assembly only once. So you have the performance drop only on the first call.

kine · 2012-05-27

IP = intelectual property....

Single instance codeunit - not working e.g. for webservices.

mdPartnerNL · 2012-05-27

kine wrote:

Single instance codeunit - not working e.g. for webservices.

Sorry, for going offtopic:

So "codeunit-A" uses a single instance "codeunit-SI"

When "codeunit-A" calls "codeunit-SI" to store a value, when "codeunit-A" calls "codeunit-B" will "codeunit-B" be able to get to the value by calling "codeunit-SI" ?

kine · 2012-05-27

Yes.

deV.ch · 2012-05-29

well ok but IP is a problem of .net in general... i mean nothing is easier then reading & extracting the source of a .net program...
But of course generating an "assembly" this way shouldn't be your first decision

Ok so webservices are a problem. Hmm but you could create the assembly not only in memory but write it to the local directory of the server(s), then you could load it from there, and only recompile it if it doesnt exists or if it's outdated.

Anyway i don't have any productive idea to use this sort of code distribution right now

Lets see what the future brings.

Howdy, Stranger!

Quick Links

Categories

Performance: interop Object vs 'native' cside code

Comments