If not .Net then what?

[jim]

I'm going to break my habit here and place a reply/post to the original
post you made.


There's plenty. As evident in other posts here, Delphi is one of them. Be
sure to evaluate carefully which version you *need* though, as the latter
versions have gotten steadily more buggy/unstable, at least that has been
my experience.

Well, that's pretty much takes Delphi out of the running then. I create
enough bugs myself - don't really need much help in that area.

I would very much like to know why you have this criteria. While I can
understand the wish to not having to include, or force the download of, a
multi-megabyte runtime engine, everyone I've talked to (all levels of
users) seems to prefer an installation program to take care of things like
correct location on disk, start menu items, uninstallation, etc.

There's installer applications that doesn't add that much to the final
size as well so size should not be a big deal in that respect either.

The idea (in addition to avoiding denpendencies wich can change on a user's
sytem) was to also be able to run the single exe apps from USB drives or
even from websites. The idea being that the more places you can run the
apps, the more people can (and hopefully will) run the apps.

You'll pretty fast find out that any development engine worth its own cost
will be a complex endeavour. If you pick Delphi or C#, just to take two
examples, you'll find that most of your time will not be spent learning
the language, although C# with its latest 3.0 version is rapidly building
up speed in the complex arean. Instead, most of your time will be spent
either looking through the runtime classes to figure out which ones to use
and how to use them, or online googling for 3rd party libraries or
examples of what you need to do.

This holds true for VB, Delphi, C#, Java, and C++ and many other systems.

Your best option against this uphill battle is to pick one development
tool and get good at it. When you're good at one of them, switching isn't
going to be that tough since a lot of things are similar enough for you to
find them more easily once you've learned how to find them in one system.

I've considered C# (since a lot of examples are written in it and they'd
help me to learn more quickly), but I used to code in VB and feel more
comfortable with that language.

Anothe plus for C# is that the syntax is similar to C++ - another language
I'd like to learn.

This still holds true, to a certain degree. I've found that the best
option to combat this is to do one of the following:

1. bundle the .NET runtime with your installer (making it bigger)
2. make the installer download and install the runtime, if necessary
3. add a link on your download page to the runtime downloads

To be honest, I prefer solution 1, with two installers, one with the
runtime and one without. This way the downloadee (?) can pick the right
one for his machine, and even install it offline.

Since these apps are mostly free (being a hobbyist coder and all) I would
choose option 2. That option would keep things as simple as possible for
most users and still dl the framework if needed.

Personally I would go with C#, but I already know C#. I don't know if this
is a good enough answer for you though. If you absolutely cannot use .NET,
I would pick another system, but each system have its pros and cons,
you're going to have to pick the ones you care about.

I may take the plungs and go C#. I always have hated the syntax of C#/C++,
but the vast amount of examples written in C# and the power of C++ are
mighty compelling.

Thanks for your post.

jim

 

[Scott Roberts]

Scott Roberts said:


Ah, I approve.

Okay - *at the time*, no, we didn't bother. We simply showed the boss the
comparative figures, and he agreed that there was no point in continuing
with .Net. After all, everyone has deadlines, and we'd already beaten
ours. The last thing anyone wanted was to add another three months to the
project while we fiddled around trying to figure out how to get Yet
Another Microsoft Technology to do as it's told. It was that or deliver
fast code, early, within budget. We chose the latter. Wouldn't you?

I'm curious why your boss even wanted to investigate .Net since the project
was already complete. Don't you generally choose a platform *before* you
begin such a project?

Later on, however, one or other of us (I forget which) discovered (I'm not
sure how authoritatively) that, apparently, .Net is not good at heavily
recursive code, and since our code did little else *but* recurse (its
function was to extract dependency relationships from source code, and
much of this was achieved by parsing the source to look for stuff like
#include "foo.h", <a href="yadayadayada.html">, etc etc - and parsing is
an inherently recursive process), this may go some way towards explaining
the huge performance disparity between .Net and native code.

Yes it does. I learned something today too.

From http://msdn2.microsoft.com/en-us/library/ms998574.aspx

"Common Performance Issues
During your code reviews, pay particular attention to the following areas:

Frequent code paths. Prioritize your code review process by identifying code
paths that are frequently executed and begin your review process in these
areas.
Frequent loops. Even the slightest inefficiency inside a loop is magnified
many times over depending on the number of iterations. Specifically watch
out for repetitive property access inside your loops, using foreach instead
of for, performing expensive operations within your loops, and using
recursion. Recursion incurs the overhead of having to repeatedly build new
stack frames. "


Of course we all know that any recursive routine can be rewritten as an
iterative routine. So I still contend that the "problem" was with your code
(specifically, it's lack of optimization for the new platform).

 

[Lasse Vågsæther Karlsen]

Well, that's pretty much takes Delphi out of the running then. I create
enough bugs myself - don't really need much help in that area.

Well, to be honest, I'm perhaps a bit vauge here. What I mean to say is
that latter versions of Delphi is unstable in themselves. The code they
produce seems fine though.

The idea (in addition to avoiding denpendencies wich can change on a user's
sytem) was to also be able to run the single exe apps from USB drives or
even from websites. The idea being that the more places you can run the
apps, the more people can (and hopefully will) run the apps.

Running the application from a external drive without installing it is a
good goal, but doesn't necessarily mean that you need to limit yourself
to one file in total. FireFox comes to mind and requires a whole host of
files and directories to be present.

Running it from the web is an entirely different ordeal though and will
likely involve either using ClickOnce deployment or running the app with
severly limited rights. Unless you mean that you want to click the
Open/Run button in the IE/FireFox download dialog and run the program
from the cache, in which case the program might be gone later.

 

[Andre Kaufmann]

Scott Roberts said:

[...]
Later on, however, one or other of us (I forget which) discovered (I'm not
sure how authoritatively) that, apparently, .Net is not good at heavily
recursive code, and since our code did little else *but* recurse (its

Recursive code doesn't IMHO cause a performance problem in .NET. This is
rather a problem for unexperienced C++ programmers placing large objects
on the stack.

That remembers me of a famous article in a German computer magazine,
stating that Java is multiple times faster than C++.
But the author(s) used std::string objects in C++ like Java string
objects and passed them by value, instead as reference. So the C++
compiler copied always the strings to a temporary object on every
function call. And since the code was heavily recursive .....

Do you see the similarities ? In this case the author stated that the
same code did run several times faster in a managed language, than in
C++. I think you are stating currently the opposite ;-)
And if the author would have done the same as your team, he wouldn't
have touched C++ again, because it's so damn slow.

I think the function in your code, which is called recursively uses a
string parameter in it's arguments.

function was to extract dependency relationships from source code, and
much of this was achieved by parsing the source to look for stuff like
#include "foo.h", <a href="yadayadayada.html">, etc etc - and parsing is

There would have been several other possibilities in .NET:

a) Use regular expressions - provided in .NET directly. You have the
option to use on the fly compiled regular expressions in .NET

b) Use a full fledged parser like ANTLR

c) Compile a mixed mode application in .NET
The native part is still native and the other code, using .NET will
be compiled to IL code.
Has downsides, but sometimes still the fastest solution

d) Convert the Code to the .NET platform, not simply recompiling

E.g. replacing the text "oldtext" by "newtext" in a single text file
named "myfile.txt" could be done in a single line in .NET (C#)

File.WriteAllText(
File.ReadAllText(
"myfile.text".Replace("oldtext",
"newtext")), "myfile.text");

(Despited my newsreader wrapped to single line to 3 lines ;-) )

Perhaps good enough for small files, but not a good idea for large
files. So even in .NET there are multiple solutions, some are
faster to implement, but performance wise not always a good idea.

an inherently recursive process), this may go some way towards explaining
the huge performance disparity between .Net and native code.

What about profiling ? Takes only a few minutes.

All in all just the meaning of a "pointy-clicky" developer ;;;-)

By the way. The same way you've (as I assume) ported your code to .NET
Quake II (IIRC) has been ported - simply by recompiling and has reached

90% of the original speed of the native compiled application.

Andre

 

[jim]

Well, to be honest, I'm perhaps a bit vauge here. What I mean to say is
that latter versions of Delphi is unstable in themselves. The code they
produce seems fine though.


Running the application from a external drive without installing it is a
good goal, but doesn't necessarily mean that you need to limit yourself to
one file in total. FireFox comes to mind and requires a whole host of
files and directories to be present.

Running it from the web is an entirely different ordeal though and will
likely involve either using ClickOnce deployment or running the app with
severly limited rights. Unless you mean that you want to click the
Open/Run button in the IE/FireFox download dialog and run the program from
the cache, in which case the program might be gone later.

ClickOnce deployment over thw web really got me excited....then I found out
how limited it was....

jim

 

[Bart C]

Excuse me? We already had working code - and you want us to *rewrite* it?
As in, write it *again*? I Don't Think So. We already had a solution that
worked well and worked fast. We tried it on .Net and suddenly it took ten
minutes instead of ten seconds.

For me that would be intriguing. 60x is a big slowdown. What was the main
reason for the slowdown? .Net is not interpreted as far as I know (it runs
some intermediate language via JIT compiler or whatever?).

It would be interesting to found out why: maybe you could have fixed
something that made it run *faster* than what you had. Or maybe you'd
discover some basic truth that you can use as an argument against .Net.

Perhaps you were not motivated enough and were relieved at the results.

Bart

 

[jim]

ClickOnce deployment over thw web really got me excited....then I found
out how limited it was....

I really don't get Microsoft's decision to move away from activeX. ActiveX
was THE web app development tool, IMHO.

You could (and I did) basically develop complete applications as activeX
controls and have them run in the browser.

I even wrote an activeX control to repair damage done by a virus that had
been set loose in the company I was working at once.

ActiveX had almost everything you needed to develop apps that really ran
across the internet.

Oh well....

jim

 

[gerry]

On 28/12/2007 in message <[email protected]> jim
wrote: ....

VS is much too web-centric.

...

wow - now there is a very revealing statement !

 

[CBFalconer]

jim wrote:
.... snip ...

Unless your app specifically targets users with old Windows
version and/or slow dialup internet connections, then I can not
see a problem going with .NET !

How about the fact that it won't run on real operating systems?

 

[Richard Heathfield]

Scott Roberts said:

I'm curious why your boss even wanted to investigate .Net since the
project was already complete.

(Well, we were halfway through testing, actually. But yeah.) Company
policy, basically. .Net had (literally) just been released, and this
client was, they said, one of the first companies in the UK to get hold of
the release version. Their policy was to switch every possible project
over to .Net as soon as was practicable. Hence the edict from on high to
investigate the practicality thereof - which we did, to our complete
satisfaction.

Don't you generally choose a platform
*before* you begin such a project?

No, actually. Why would the *platform* matter? Who gives a stuff?

In this case, we wrote the code in ISO C++ (plus Berkeley sockets)
specifically because we didn't know what platform it would eventually run
on. We favoured putting it on a Unix box, which is why we made it drivable
via a socket - just in case a miracle happened and we got our way. We
actually developed on Cygwin and Linux (because we liked g++), but then we
were told to port it to Windows. That took - oh, ten minutes or so,
basically hacking around at the sockets code. Then we were told to port it
to .Net. If we'd been silly enough to make it platform-specific at the
beginning, we'd have run out of time or money or both.

Recursion incurs the overhead of having to
repeatedly build new stack frames. "

Well, duh.

Of course we all know that any recursive routine can be rewritten as an
iterative routine. So I still contend that the "problem" was with your
code (specifically, it's lack of optimization for the new platform).

Nonsense. Natively, it ran like a ferret up an accordionist's trousers, so
clearly there is no intrinsic obstacle to good performance on recursive
programs. If .Net can't handle recursion, it is not suitable for problems
that are best expressed recursively.

The whole reason for having high level languages is so that you can express
the problem in the problem domain. If the problem is recursive (and
language parsing /is/ recursive in nature), then a recursive solution is
practical and sensible. Removing the recursion at source code level for
the benefit, not of the programmer, but of the *computer*, is Just Plain
Daft.

Optimising for the platform is all very well, but one should optimise the
platform too if possible, and in this case the optimum platform is
achieved when one removes an entire useless abstraction layer and lets the
code run natively.

 

[Richard Heathfield]

Andre Kaufmann said:

Scott Roberts said:

[...]
Later on, however, one or other of us (I forget which) discovered (I'm
not sure how authoritatively) that, apparently, .Net is not good at
heavily recursive code, and since our code did little else *but* recurse
(its

Recursive code doesn't IMHO cause a performance problem in .NET.

Well, if that wasn't it, it was something else. Certainly the performance
problem existed.

This is
rather a problem for unexperienced C++ programmers placing large objects
on the stack.

No. If that were true, the native code would have run slowly too. Remember
we are talking SIXTY times slower on .Net than natively.

<snip>

 

[Richard Heathfield]

Bart C said:

Perhaps you were not motivated enough

It is certainly true that we were not highly motivated to "fix" a working
program.

and were relieved at the results.

Well, no - having spent time on the port, we were *annoyed*[1] at the
results, not least because it meant we'd have to spend time arguing with
the Powers That Be. If everything had gone sweet as a nut, that would have
suited us fine.

[1] Actually, our first reaction was "it's crashed", and we spent some time
looking for a cause. It took some time for us even to consider the
possibility that it might be a performance issue, because no program takes
*that* long...

 

[Romeo Props MICHALE the A$$]

How about the fact that it won't run on real operating systems?

You can crawl back under a real rock you POS.

 

[Dennis]

Just noted your comment about industrial use of Windows. I'm just curious
what you consider industrial? I work for the world's largest public company
(maybe you've heard of ExxonMobil) and guess what system they use...you
guessed it "Windows"!
--
Dennis in Houston

[followups set to comp.programming, where I'm reading this thread]

Terry Olsen said:

The only objection to the .NET framework I've heard is from people who
say they don't want some big runtime library installed on their pc's.

Another objection is that it's slow. The first program I moved to .Net ran
around 60 times slower than native - way too slow to be useful.

A third objection is that it's non-portable. Even if I were of a mind to
run .Net programs under Linux, I couldn't actually do so - at least, not
yet. Mono promises to sort that out... oonnee ddaayy...... but in the
meantime Linux users would rather have something that actually works.

I use VB not because i'm stupid, but because I'm lazy.

Being even lazier than you, I use C++ Builder for those rare occasions when
I need to write a Windows program. Because I'm so lazy, though, I prefer
to use Linux, where almost everything is so much easier to do. (In the
interests of balance and fairness, I will of course concede that there are
some things that it's easier to do in Windows. But industrial-strength
programming isn't one of them.)

I like that I can
whip out a windows form in a few seconds and use the various built-in
functions and classes to do the work that I want done. I've been known to
get a quick app done in 15 minutes when someone says "I need a utility to
do this...".

What took you? My personal record for responding to such a request is 30
seconds (including compilation) for the first version, and another 60
seconds when the user suddenly decided to require some extra features.
Builder rocks like that. I recommend it to you - and it doesn't need that
silly .Net framework either.

Using a non-ide language like gcc or other command-line
compilers doesn't make any sense to me. It's a time waster.

I don't like wasting my time, which is why I use the best tool for the job.
Sometimes, that's an IDE tool like C++ Builder. But sometimes it's a
command-line tool. If you think command line compilers are a waste of
time, that suggests that you haven't much experience of life outside the
world of pointy-clicky.

So it's up to you. Use whatever you're comfortable with and don't listen
to people who have pre-conceived ideas about your language of choice.

There, at least, I can agree with you.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

 

[Dennis]

Why are you even monitoring this newsgroup if you are so "anti .net"?

 

[Arne Vajhøj]

Just noted your comment about industrial use of Windows. I'm just curious
what you consider industrial? I work for the world's largest public company
(maybe you've heard of ExxonMobil) and guess what system they use...you
guessed it "Windows"!

I know nothing about Exxon, but I serious doubt that they only use
Windows.

A company of that size typical use Windows on the desktop and
windows + 2-3 flavours of *nix + 1-2 other OS's on servers
scattered over 6 continents.

Arne

 

[Arne Vajhøj]

Why are you even monitoring this newsgroup if you are so "anti .net"?

If you have read the thread carefully, then you would have
seen that the original poster for some reason included
comp.programming in the distribution, so it indeed went
out to non-.NET and non-Windows programmers.

Arne

 

[Andre Kaufmann]

Andre Kaufmann said:


No. If that were true, the native code would have run slowly too. Remember
we are talking SIXTY times slower on .Net than natively.

Sorry if you got me wrong.

I meant it generally not related to you. It's easier even for
experienced C++ developers to write slow recursive functions than .NET.
Shouldn't mean that your C/C++ application was slow too or that your
team was unexperienced - regarding C++.

[...]

Recursive code doesn't IMHO cause a performance problem in .NET.

Well, if that wasn't it, it was something else. Certainly the performance
problem existed.

Well I simply state you hadn't a performance problem, just used the
tools wrong.

You haven't mentioned how you have converted your C/C++ code to .NET.
Normally that isn't quite simple and even if most of the code
recompiles, commonly you have compiled a mixed application consisting
out of managed + native code, which shouldn't be slower.


But perhaps you / you're team has done common mistakes of developers
used to C++ Builder are commonly doing, when using MS VStudio for the
first time:


1) Visual Studio .NET C++ compiler is generally .NET code.

No - it's still a native compiler and special options have to be set
to generate true "IL" code (PURE / SAFE) mode



2) Debug / Release Version

Commonly Debug versions compiled in Visual Studio are slower.
Depending on the settings and application this may be up to
100 times slower.

By Default Visual Studio generates a Debug and a Release
configuration, but enables Debug by default.


So if you don't write *how* you have converted your code to .NET, I
simply state you haven't had a performance problem related to .NET but
just another performance problem, unrelated to .NET. ;-)

<snip>

Take for example iostreams in C++, I can write easily applications in
C++ that are 60 times slower than their C# counterparts. Does that mean
that C++ is generally slower ?


Short example, which illustrates potential performance problems,
regarding strings, which are always Unicode strings !:

a) C++: (string buffer not reserved - bad performance)

std::string s;
for (size_t i = 0; i < 0x2000; ++i)
{
s+= "text";
}

######
###### < 1 ms.
######


b) C++/CLI - .NET:

System::String^ s = "";

for (size_t i = 0; i < max; ++i)
{
s+= "text";
}

######
###### > 2000 ms.
######


c) C++/CLI .NET - Optimized

System::Text::StringBuilder^ s = gcnew System::Text::StringBuilder();

for (size_t i = 0; i < max; ++i)
{
s->Append("text");
}


######
###### < 0 ms.
######


Andre

 

[Richard Heathfield]

Andre Kaufmann said:

Well I simply state you hadn't a performance problem, just used the
tools wrong.

<shrug> I know the performance problem existed, and I know it went away
when we stopped using .Net - make of it what you will.

 

[Miha Markic]

when we stopped using .Net - make of it what you will.

Imagine a person used to drive a Zastava Yugo. He knows it to the bones.
Now, let's imagine that he tries a brand new Lamborghini Diablo and because
his lack of knowledge he can't even start it up.
Now, he doesn't bother to RTFM, nor he asks anybody how to start it up.

The conclusion? Diablo sucks while Yugo rules.