Performance: interop Object vs 'native' cside code

nXqd
nXqd Member Posts: 39
edited 2012-05-29 in NAV Three Tier
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,

Comments

  • deV.ch
    deV.ch Member Posts: 543
    Well.. is it just me or is there no question in your post ? :D
    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!
    My Blog
  • nXqd
    nXqd Member Posts: 39
    deV.ch wrote:
    Well.. is it just me or is there no question in your post ? :D
    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
    Sog Member Posts: 1,023
    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.
    |Pressing F1 is so much faster than opening your browser|
    |To-Increase|
  • deV.ch
    deV.ch Member Posts: 543
    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.
    My Blog
  • kriki
    kriki Member, Moderator Posts: 9,121
    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.
    Regards,Alain Krikilion
    No PM,please use the forum. || May the <SOLVED>-attribute be in your title!

  • DenSter
    DenSter Member Posts: 8,307
    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#.
    Daniel Rimmelzwaan
    RIS Plus, LLC
  • DenSter
    DenSter Member Posts: 8,307
    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#.
    Daniel Rimmelzwaan
    RIS Plus, LLC
  • davmac1
    davmac1 Member Posts: 1,283
    You sure it was not intended as a "trial balloon"? :)
    David Machanick
    http://mibuso.com/blogs/davidmachanick/
  • kine
    kine Member Posts: 12,562
    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...
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • deV.ch
    deV.ch Member Posts: 543
    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?
    My Blog
  • nXqd
    nXqd Member Posts: 39
    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
    Sog Member Posts: 1,023
    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
    |Pressing F1 is so much faster than opening your browser|
    |To-Increase|
  • deV.ch
    deV.ch Member Posts: 543
    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
    My Blog
  • nXqd
    nXqd Member Posts: 39
    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
    kine Member Posts: 12,562
    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:
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • deV.ch
    deV.ch Member Posts: 543
    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.
    My Blog
  • kine
    kine Member Posts: 12,562
    IP = intelectual property....

    Single instance codeunit - not working e.g. for webservices.
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • mdPartnerNL
    mdPartnerNL Member Posts: 802
    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
    kine Member Posts: 12,562
    Yes.
    Kamil Sacek
    MVP - Dynamics NAV
    My BLOG
    NAVERTICA a.s.
  • deV.ch
    deV.ch Member Posts: 543
    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.
    My Blog

Categories