.NET *Fails*

  • Thread starter Thread starter C# Learner
  • Start date Start date
C

C# Learner

I've just recently messed with .NET /controls/, and I can't say I'm
impressed. Several of them appear to be *highly* inefficient when it
comes to screen updates (see my thread "ListView Unbearable" for a major
example of this).

These tests were run on a *brand new* PC, too. I can't bear to think
how badly this would affect slightly older systems.

From this I can only conclude that the idea of .NET -- the idea of a
more-or-less purely-object-oriented framework that lends itself well to
RAD -- is too good to be true. I kidded myself in the beginning that
this could work, but how wrong I was.

Maybe at some point in the future, computer systems will be powerful
enough for this; but, for now, we can only hope and wait.
 
Please see your "ListView Unbearable" thread. I have not seen problems like
what you are describing in this and the other thread.

Richard
 
Lets see here..

I've seen many posts from you lately, all negative and or complaints...
Maybe you'd be better suited with another platform? I hear that people love
programming for the Mac...

Last time I saw your post you were complaining that you actually had to
write some code... Did you expect to write something like:

public MyApp()
{
Create.MyPerfectApplication();
}


???


Sorry for being short, but, if you're not happy, do youself a favor and move
on, no need to try to influence anyone else. We'll all find out if it's not
for us on our own.
 
I've just recently messed with .NET /controls/, and I can't say I'm
impressed. Several of them appear to be *highly* inefficient when it
comes to screen updates (see my thread "ListView Unbearable" for a major
example of this).
These tests were run on a *brand new* PC, too. I can't bear to think
how badly this would affect slightly older systems.

Well, by the time your app will be ready, most users will probably
have a more powerful machine than what you used here for testing.

If you don't like .NET, and the power and flexibility it gives you,
you're free to go back to assembler and hand-craft your stuff - good
luck with keeping those deadlines !

There's always a trade-off between being quick to market, and being
efficient. Where do you really want to sink all your development
effort into? Making that screen update 2% faster?? Or getting your app
out so that users can start using it?

Your call if you're on your own - your manager's call, if you're on a
deadline.....

Marc
================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
Marc said:
Well, by the time your app will be ready, most users will probably
have a more powerful machine than what you used here for testing.

If you don't like .NET, and the power and flexibility it gives you,
you're free to go back to assembler and hand-craft your stuff - good
luck with keeping those deadlines !

There's always a trade-off between being quick to market, and being
efficient. Where do you really want to sink all your development
effort into? Making that screen update 2% faster?? Or getting your app
out so that users can start using it?

It's not about two percent. The .NET controls I'm having problems with
are *unbearably* slow and flickery. It makes apps that use them looks
*awful*. They're show-stoppers.

<sarcasm>
But, hey, I can always go back to the command-line interface, right?
</sarcasm>

I would not *use* an app with controls this bad, let alone *pay* for one.
 
Please see your "ListView Unbearable" thread. I have not seen problems
like
what you are describing in this and the other thread.
First of all, I doubt that Listview is a pure .NET control, I have the
impression that it is just a wrapper to the unmanaged ListView control also
used by C++ and MFC.

I believe that the problems you encounter is because of some other cause.
Maybe some other thread that runs in your program, taking up a lot of
processor time.
Maybe you allocated so much memory that your computer started swapping
memory to disk, slowing down processor time.
Maybe your TestListView() function is called again during the processing of
TestListView() which makes this recursive.
Maybe you have some profiling active trying to measure speed statistics in
the background.

The problem is that we do not see the complete code, if you could post a
project, then we could test it here too.

(In the beginning I also thought that this .NET thing was bad, but it all
turned out to be security related problems, and the use of mixed
managed/unmanaged code that used the mfc, and one installation problem
regarding the WINDIR environment variable that got corrupted). So far I have
not seen direct evidence that C# creates bad or slow code.
 
[...]
I believe that the problems you encounter is because of some other cause.
Maybe some other thread that runs in your program, taking up a lot of
processor time. [...]

That code *is* the whole program. The only other code is a button click
event handler that calls TestListView().

I'll post a complete program that demonstrates it in a while.
 
TonyM said:
Lets see here..

I've seen many posts from you lately, all negative and or complaints...
Maybe you'd be better suited with another platform? I hear that people love
programming for the Mac...

If no-one ever complained, things wouldn't improve half as fast as they do.
Last time I saw your post you were complaining that you actually had to
write some code...

No, that was not the case. I was complaining about .NET missing some
obvious functionality, which forces me to make a library routine and
distribute it with any apps that I make that need the functionality.

Note that TryParse() is being added to other types soon, possibly due to
someone else complaining about it.
Did you expect to write something like:

public MyApp()
{
Create.MyPerfectApplication();
}

I fear the day when programming gets anywhere near that stage.
 
It's not about two percent. The .NET controls I'm having problems with
are *unbearably* slow and flickery. It makes apps that use them looks
*awful*. They're show-stoppers.

Not sure what the heck you're doing, then, because we use lots of the
..NET components, and some third-party components, and we would have
never experienced anything like this. Screen flicker or slow updates
are actually DOWN from previous C++ code.

Are you properly using .BeginUpdate / .EndUpdate calls? Are you maybe
experiencing a graphics card driver problem?

I don't see anything in .NET to suggest that screen update performance
is worse than before.

Except for a short delay at the very first startup, we actually don't
see any noticeable performance degradation of ANY kind with the .NET
framework and components.

And productivity and speed of development are WAY UP - so from my
point of view, .NET "ROCKS* and makes it just that much easier and
quicker to develop great Windows apps

Marc
================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
Marc said:
Not sure what the heck you're doing, then, because we use lots of the
.NET components, and some third-party components, and we would have
never experienced anything like this. Screen flicker or slow updates
are actually DOWN from previous C++ code.

Are you properly using .BeginUpdate / .EndUpdate calls?
Yes.

Are you maybe
experiencing a graphics card driver problem?

Not as far as I know, but I'll have to look into this, among other things.
I don't see anything in .NET to suggest that screen update performance
is worse than before.

Except for a short delay at the very first startup, we actually don't
see any noticeable performance degradation of ANY kind with the .NET
framework and components.

And productivity and speed of development are WAY UP - so from my
point of view, .NET "ROCKS* and makes it just that much easier and
quicker to develop great Windows apps

Okay, I believe you. I just wish I could say that.
 
My working hypothesis, right now, is that .NET has exposed some kind of bug
in a few video drivers, because a couple of people have reported lots of
flicker, and the rest of us have never seen it happen.
 
It must be a device driver problem because in 3+ years of .NET (since the
NGWS alpha) I have never seen this, even after working for dozens of
clients.

--
-----
Sam Gentile
Microsoft MVP - C#/.NET
..NET Blog http://samgentile.com/blog/

Please do NOT contact me directly but respond to
the newsgroup instead.
 
Back
Top