Board index » delphi » Is .NET right for small utilities that need to run all the time?

2007-07-12 01:47:44 AM
delphi157
Is .NET right for small and simple utilities that need to be running
most of the time?
I have to write a small timer utility that shows up on the desktop all
the time.
Is .net going to be an over kill for such utilities, in terms of the
memory / recourses it needs?
Thanks,
Sarah
 

.Net is not good for small utilities. It is also no good for
pseudo-real-time apps.
--
Mark Jacobs
www.jacobsm.com
"Sarah" <XXXX@XXXXX.COM>writes

After serious thinking Sarah wrote :
program so I could remap some of the Windows key combinations. I read
about a few and found one that had the features I needed and look good
to boot. One requirement caused me to pause, .NET. Oh well, I will give
it a try. (The utility is popular but I don't remember its name.)
So I installed the software, fixed my mappings, and found the software
would always take about 20MB of memory. This is a utility that has to
stay loaded all the time. For what I was doing, I thought this was too
much. I did some more searching and found AutoHotKey, a Win32
application.
AutoHotKey doesn't have a {*word*226} interface, but it could everything the
other utility could do and about 10x more. With all of this power, it
must have a larger memory footprint. Right? No. It seems to always
float below 5MB.
That's the long answer to say "No" to your question. Your mileage may
vary.
And for anyone interested in AutoHotKey, here are some cool things you
can do with it.
www.lifehack.org/articles/technology/10-ways-to-use-autohotkey-to-rock-your-keyboard.html
 

"Sarah" <XXXX@XXXXX.COM>writes
newsreader in anticipation of reading some useful replies based on facts as
opposed to unsubstantiated personal opinion. I hope you get some. (I mean,
I love to bash .NET as much as the next guy, but I have developed a couple
of smaller C# apps with it, and it wasn't an unpleasant experience!)
--
Ray Marron
 

Mark Jacobs writes:
Thanks,
Sarah
 

Sarah writes:
in a corporate environment and control the desktop in that you know the
.Net Framework is going to be installed, then it is probably fine.
If, however, you are talking about a commercial/shareware/ISV type
application, then you'd want to go native because you probably wouldn't
want the burden of ensuring that customers have the .Net Framework
installed.
--
Nick Hodges
Delphi Product Manager - CodeGear
blogs.codegear.com/nickhodges
 

Mark,
--
marc hoffman
RemObjects Software
The Infrastructure Company
www.remobjects.com
 

Sarah writes:
utility as a .net application?
If so, then you can absolutely do what you want using any .Net
language. It just wouldn't be my first choice.
1) The end user must have the correct version of the .net framework
installed.
2) A simple WinForms application with a label and a timer uses 3-4
times as much memory as a Delphi Win32 equivalent (I selected Release
mode). This memory usage is cumulative. If one instance of the
application uses 12MB (which this one does), all instances use the same.
3) There is a visible lag when the application starts up as it gets
jitted for the first time.
4) WinForms paints noticeably slower than the VCL.
However, these last two probably won't be much of a problem with a
small utility with a simple UI.
Someone might call this .Net bashing. I just think .Net is better
suited to server and ASP.Net applications.
--
Regards,
Bruce McGee
Glooscap Software
 

Nick Hodges (CodeGear) writes:
But is it still worth developing a small utility in .net?
(It's small but needs to run all the time like a service app).
Again I have two scenarios:
1. My util is the only .net app run on a PC
2. More than one .net apps are running on the same PC
In fact, we don't have any .net apps running on our PCs at this time.
But that *might* change in future by having heavy duty database apps
developed in .net.
Sorry, if I am asking too many dumb questions! :)
Thanks,
Sarah
 

Sarah writes:
memory use that you'd necessary like. Not for sure, but it could.
--
Nick Hodges
Delphi Product Manager - CodeGear
blogs.codegear.com/nickhodges
 

On 2007-07-12 04:51:04 +1000, "Mark Jacobs" <XXXX@XXXXX.COM>said:
works perfectly fine.
 

"Sarah" writes:
Make the decision on the basis of what your developer's (and managers) are
most comfortable with. If they know how to leverage the .NET framework it
becomes both feature rich and efficient.
If you base your decision on minimizing the memory requirements as reported
by task manager you will always choose native over managed. If you truly
want minimum memory then use Delphi without the VCL or better yet code in
ASM.
The way Windows and .NET actually manage memory is very complex, hard to
grasp, and in a perverse sense quite efficient. .NET apps always over
allocate memory but readily give it up if Windows decides some of that
memory is better used elsewhere. Rather than worry about how much memory
your app shows in task manager, worry about memory leaks and if performance
is critical then use a good profiling tool in your development cycle.
I don't think your two scenarios provide sufficient criteria for choice. For
years I have had a .NET service utility on my machine that loads on startup
and sets in the taskbar notification area. If I never intended to load
another .NET app I'd still use it.
 

Kyle A. Miller writes:
AFAIK the DLL's of the framework have been NGEN'd (pre-compiled into
native code). This turns them into normal Win32 DLL's that don't need to
be recompiled each time they are loaded. So the "normal" DLL rules
must apply.
If the base addresses were determined accurately by Microsoft and
don't overlap, they will be in *physical* memory only once (mapped
as memory-mapped-files) even if each .NET task sees them in its
own *logical* address space.
For comparison: Each native Win32 task has "user32.dll" , "kernel32.dll"
and some other huge monsters in its address space. Still these are
only present once in the physical address space...
--
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
 

I have a small text processing utility that I use almost every day. When Delphi 8 arrived,
it was one of the first applications I recompiled for .NET. Other than a barely noticeable
delay on first start the new version works identical to the old one. I haven't bothered to
recompile the utility back to Win32.
 

Sarah writes:
My notebook has an ATI graphics adapter (I guess some
50% of the world uses these). The configuration program
which resides in the task bar permanently (ATI catalyst control
center) is a .NET application.
AFAIK the amount of *physical* memory that the .net framework
occupies doesn't grow much with the loading of additional .NET
applications.
--
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)