.Net Architecture question

  • Thread starter Thread starter Aaron
  • Start date Start date
A

Aaron

is it faster, performance-wise to use as fewer
libraries/namescape(?not sure wht they are called. ie using System.IO)
as possible?

i wrote a program that has about 3000 lines of code, and there's only
one function that needs to do some xml-like string manipulation. It'd
be easiest to use one of the functions from the System.Xml namescape,
but I don't how that will affect my program's performance and size. or
i can write a function with regex, takes a lot more work.

Thanks in advance
Aaron
 
kuya789 said:
i wrote a program that has about 3000 lines of code, and there's only
one function that needs to do some xml-like string manipulation. It'd
be easiest to use one of the functions from the System.Xml namescape,
but I don't how that will affect my program's performance and size. or
i can write a function with regex, takes a lot more work.
Click to expand...

It has no effect. The entire framework will exist on the users machine
(including all XML, WebService, IO libraries, etc...). There is no
static linking in .NET.
 
is it faster, performance-wise to use as fewer
libraries/namescape(?not sure wht they are called. ie using System.IO)
as possible?

i wrote a program that has about 3000 lines of code, and there's only
one function that needs to do some xml-like string manipulation. It'd
be easiest to use one of the functions from the System.Xml namescape,
but I don't how that will affect my program's performance and size. or
i can write a function with regex, takes a lot more work.
Click to expand...

Using any namespace in the standard .NET class library does not make your
code bigger. The resulting assembly will only contain a reference to the
used namespace, none of the actual code is included in your assembly. The
code is in the .NET framework assemblies that are present anyway on the
target machine whether you deploy your assembly or not..

In the old days when people used to program in Visual C++ they could choose
whether to built their projects using static linking or dynamic linking.
Static linking would draw all dependencies into your executable, making your
"Hello World" application about 1.5 MB in size. Dynamic linking just hooked
into some of the MFC dlls and would keep the executable's size very small.
Static linking could nevertheless be a valid option since the dependencies
(these dlls) were installed with Visual C++. Users/clients typically did not
have Visual C++ (or equally worse, had a different version) and your
dynamically linked app would not run on their machine. And you would tell
your user/client "It works on my machine.". Just what he wanted to hear. You
get the picture.

With the .NET framework life is good. Any class library dependencies are in
the .NET framework which is an integral part of any .NET enabled machine so
there is no need to deploy bloated code anymore. There still is the issue of
versioning, an application written for one version of the framework may not
run on a different version but the writer of the application has full
control over specifying compatibility demands. Newer framework versions may
be allowed while earlier versions may be declared unfit. The CLR will check
your demands before running your app.

Martin.
 
When you use another library, the primary overhead is loading that assembly
into memory and doing the necessary JITing. That discounts the overhead
associated with the types you are using - in your case, XMLDocument might be
expensive to create and use.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://weblogs.asp.net/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top