whats faster, initialize component, or form load?

[Guest]

hey, I have some preliminary code in my program (check for a certain file,
define a like 15 variables) and I put it in the form load. I recently got
the idea to make a method for it, and do it in the constructor method instead.

would this make the load time of the program faster? or is it the same as
leaving it in the form load.? any thoughts or ideas on this?

thanks.

 

[Peter Duniho]

hey, I have some preliminary code in my program (check for a certain
file,
define a like 15 variables) and I put it in the form load. I recently
got
the idea to make a method for it, and do it in the constructor method
instead.

would this make the load time of the program faster? or is it the same as
leaving it in the form load.? any thoughts or ideas on this?

Measure it and see.

I doubt you'll find any significant difference. But there's only one way
to know for sure.

Pete

 

[Cor Ligthert [MVP]]

Roger,

It is not impossible that you win with that 30 picoseconds.
Although for the same it can be 30 picoseconds longer.

Of course the real time depends on your computer, your file IO and your type
of network.



Cor

 

[Nicholas Paldino [.NET/C# MVP]]

Roger,

In this case, no, it is not going to make the program faster. You are
doing the same work, which is going to take the same amount of time, just in
a different order. The order of operations for your program is as follows
(generally):

Create form instance
Show form
Load event on form is called

All of this is synchronous. This is an important distinction.

If hypothetically, the whole process takes 10 seconds, and it takes 5
seconds to run the Load event on the form, then moving the code that takes
five seconds to the constructor is not going to make the code run any
faster. You are still going to take five seconds to perform that work, and
the overall time will not change.

I mentioned synchronous before becuase if you can do the work
asynchronously, then you could see a benefit in speed if you delegate the
work to another thread. However, you have to figure out whether or not the
work can be performed asynchronously.

 

[Lit]

Nicholas,

Interesting, how does asynchronously make it faster?
please enlighten.

Thank you,

Lit

Roger,

In this case, no, it is not going to make the program faster. You are
doing the same work, which is going to take the same amount of time, just
in a different order. The order of operations for your program is as
follows (generally):

Create form instance
Show form
Load event on form is called

All of this is synchronous. This is an important distinction.

If hypothetically, the whole process takes 10 seconds, and it takes 5
seconds to run the Load event on the form, then moving the code that takes
five seconds to the constructor is not going to make the code run any
faster. You are still going to take five seconds to perform that work,
and the overall time will not change.

I mentioned synchronous before becuase if you can do the work
asynchronously, then you could see a benefit in speed if you delegate the
work to another thread. However, you have to figure out whether or not
the work can be performed asynchronously.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

hey, I have some preliminary code in my program (check for a certain
file,
define a like 15 variables) and I put it in the form load. I recently
got
the idea to make a method for it, and do it in the constructor method
instead.

would this make the load time of the program faster? or is it the same as
leaving it in the form load.? any thoughts or ideas on this?

thanks.

 

[Peter Duniho]

Interesting, how does asynchronously make it faster?
please enlighten.

It depends. In some cases, it won't. But if you have multiple elements
to your initialization that are mutually independent (that is, the results
of some initialization are not required in order to perform other
initialization), then you could see improved performance by processing
them asynchronously for a variety of reasons. The most common being that
on a multi-CPU computer, each asynchronous thread can do work in parallel
with other asynchronous threads.

For example, suppose that when initializing you have two different
calculations you need to do, neither of which depend on each other.
Suppose they both take 500 milliseconds. Doing them synchronously, you
would take 1000 milliseconds, but doing them asynchronously you could
theoretically do them both in only 500 milliseconds, assuming you have at
least two CPUs to handle the processing.

Another common reason would be if the initialization required a variety of
i/o to different subsystems or remote entities. An example of this might
be if you have to query two different web servers. Even if you only have
one CPU, you could still see an improvement in speed, for similar reasons
as the CPU-bound case. The difference being that in this case you are
waiting for a remote server instead of a CPU. But the basic logic is the
same: if you have to wait 500 milliseconds for each server, doing the
requests synchronously would delay you 1000 milliseconds, but doing them
asynchronously in parallel would delay you only 500 milliseconds.

Now, all that said, there's little about your problem description that
suggests to me that you would gain much benefit from changing your
initialization at all, never mind making some or all of it happen
asynchronously. In particular, the only thing that sounds remotely slow
is the "check for a certain file", so you have no other slow item to do in
parallel with that. Even that operation is unlikely to be slow enough for
you to be concerned with its performance anyway. Say, for example, you
had to make two such checks. Even so, unless you were trying to
instantiate a number of this class all at once (like thousands or more), I
doubt that you'd achieve any practical performance improvement by
parallelizing the operations.

Basically, it appears to me that you are worrying about something that
simply does not warrant concern.

Pete

 

[Cor Ligthert [MVP]]

Peter,

In 80% of the situations will parallalisation imo only slow down the
process, just because the parallalisation needs to be processed. I assume
that the second part of a processor will completely eat that.

Multithreading can be helpfull in by instance your given sample where the
program needs to wait on an offline process..

I find that telling about the hyperthreading processor a fable. There are in
my computer at least 40 other tasks which are awake or running so that other
part of the processor will in my idea never given to a multithreading thread
(Or it should be with an OS where at the moment C# is not able to work).

Just my opinion,

Cor

 

[Peter Duniho]

Peter,

In 80% of the situations will parallalisation imo only slow down the
process, just because the parallalisation needs to be processed. I assume
that the second part of a processor will completely eat that.

And 98.6% of all statistics are completely made up.

Honestly, I don't find that "80%" comment to be particularly useful. I
think that if you tried to apply parallelization to ALL code, that in fact
even _more_ than 80% of it would wind up slower. But not because of the
overhead of handling multiple threads. Rather, simply because the work
being done doesn't lend itself to parallelization. I did point out in my
post that not all cases can be successfully parallelized.

For those that _can_ be parallelized, the question becomes how much
processing is actually involved. There is overhead in context switching,
but if you can use the thread pool then you don't have the overhead of
creating threads, and you don't have to have a _lot_ of processing for the
context switching to be worth it.

You _do_ have to have a lot more processing that you typically would when
simply initializing a class instance, but it appears to me that we have
diverged from the original scenario at this point. You and I are both
writing more generally, and I disagree that for those scenarios in which
the algorithm lends itself to parallelization, that you would still fail
in 80% of the situations to improve performance by taking advantage of
that.

Let me make sure I'm clear: if we're talking about a constructor that
initializes 15 value type fields, and by "parallelization" we're talking
about making a secondary thread that initializes 8 of those fields,
initializating the remaining 7 in the main thread (or worse, in another
secondary thread), then I agree this isn't going to help performance. It
takes so little time to initialize data that there's no way starting up a
new thread (even if it's already created) can be faster than just
initializing all 15 in one thread.

But the discussion is not about that scenario only, and the _general_
statements need to be true for all code that is parallelizable. Not just
the OP's question.

Multithreading can be helpfull in by instance your given sample where the
program needs to wait on an offline process..

It can be helpful for CPU-bound algorithms as well, assuming they can be
parallelized. Not all CPU-bound algorithms meet that requirement, but I
specifically excluded those from my discussion.

I find that telling about the hyperthreading processor a fable. There
are in
my computer at least 40 other tasks which are awake or running so that
other
part of the processor will in my idea never given to a multithreading
thread
(Or it should be with an OS where at the moment C# is not able to work).

You have two completely unrelated statements there. Let's look at the
latter first, the question of how many processes you have running. Yes,
on a Windows PC there are a number of processes always running. But it is
false to think that just because they are there, running multiple threads
in a single process won't improve performance.

Of those 40 processes, most are completely idle, or nearly so. They are
waiting on some kind of i/o and have exactly no CPU load until that
happens. Furthermore, even when they do want to use the CPU, they are
unlikely to use their entire timeslice. On the other hand, a CPU-bound
algorithm _will_ use its entire timeslice. It would not be uncommon at
all to find a CPU-bound, multi-threaded application that is able to
consume close to 100% of the CPU time on all CPUs, since it would normally
be the only process on the computer that actually spends any significant
amount of time using the CPU.

So, your "at least 40 other tasks" is a red herring, and has very little
to do with the success or failure of multi-threading.

So, how about the hyperthreading question? Well, a number of points are
relevant here:

-- Yes, hyperthreading is not as good as having two CPUs. However, it
_is_ better than having just one, and I have both written and used code
that shows that to be true.

-- Some caveats do apply for using HT CPUs: HT cores share a cache, so
you have to write your code carefully to ensure that multiple threads are
not trashing each others cache. You can very easily write multi-threaded
code that runs _much_ worse on a HT CPU than on a single CPU. Also,
because not all of the CPU is duplicated, only certain kinds of processing
will see any benefit, and even of the kinds of processing that can
benefit, some algorithms will do better than others. It's not like true
independently multi-CPU systems, where one can achieve very close to
optimal scaling proportional to the CPU count if the algorithm is
implemented well.

-- Most importantly, however, I never said anything about HT
processors, nor do I see any reason that this discussion should be
restricted by HT processors. Especially today, when dual-core is now the
norm and many PCs are sold with four or eight cores (and in some cases,
those cores are hyperthreaded!), thinking that one should not bother with
multithreading just because on a single-core HT system there's little
benefit is, well...fairly shortsighted.

Just my opinion,

You're welcome to it, of course. However, I'll suggest that there are
some naive assumptions behind that opinion, at least as described in your
post. When more than one CPU is available, there very often is real
benefit for multi-threaded code when the algorithm is suited to
parallelization. I think that claiming that 80% of those cases would wind
up worse off when actually parallelized is a broadly incorrect statement.

Pete

 

[Cor Ligthert [MVP]]

Peter,

Let say it than all what we in a much simpler way imo did you write in your
first message you can win proces time with parallalisation.
I say parallalisation cost forever procestime, because of that proces you
can win throughput time. However be aware that this is only in certain
circumstances.

The OP is writting about winning time not all whatever benefits that there
can be more from multiprocessing (to use the old and in my idea still
correct word for it).

I have still never heard of a successful results with parallalisation from
internal (dependable) algoritmes although there are AFAIK spent billions for
it in Japan on mainframe computers.

Cor

 

[AlexS]

I believe you need to check how modern CPUs and graphics cards are built -
they use parallel execution in several places. Or just look and compare 2
core and single core processors.

Point is, for every algorithm there is parallel version. Just like for every
algorithm there is estimate of complexity like o(n) or o(nlogn) or whatever.
Question if parallel version is faster than sequential, is usually answered
in favor of parallel. However, this kind of research requires pretty
significant effort and is worth the effort only for significant volumes of
sufficiently important data to process. And also keep in mind that parallel
algorithm usually doesn't resemble sequential version at all.

Suppose you need to initialize 1 form - parallel might not do any good
there. However if you need to initialize thousands or millions of such
forms, your only hope is parallel execution. Same applies for any kind of
data.

All kinds of modern (and grid) computing are using parallel execution and
algorithms. This is the only way to increase performance "ignoring" physical
limitations of underlying hardware.

 

[Peter Duniho]

Let say it than all what we in a much simpler way imo did you write in
your
first message you can win proces time with parallalisation.
I say parallalisation cost forever procestime, because of that proces you
can win throughput time. However be aware that this is only in certain
circumstances.

I can't parse that. Are you now agreeing with me that parallelization
_can_ improve performance? No offense intended, but the paragraph isn't
correct English (I recognize that English isn't your native language), and
I'm not able to find an unambiguous way to translate it to correct English.

The OP is writting about winning time not all whatever benefits that
there
can be more from multiprocessing (to use the old and in my idea still
correct word for it).

The OP didn't bring up parallelization at all. He was asking about moving
code from one initialization method to another. It was Nicholas who
mentioned parallelization and the possibility of doing the work
asynchronously, and it was to that point that I was responding (since the
OP asked for clarification).

I have still never heard of a successful results with parallalisation
from
internal (dependable) algoritmes although there are AFAIK spent billions
for
it in Japan on mainframe computers.

Parallelization happens all the time. You are simply uninformed if you
think it's limited to supercomputing.

As a quick example, any of the numerous audio and video transcoding
software available that is worth using takes advantage of
parallelization. Even Windows Movie Maker, available for all Windows
computers since Windows XP, uses multiple threads for transcoding. That
design is standard for any retail software that does similar work.

Pete

 

[Cor Ligthert [MVP]]

Alex,

Can you give me a real world situation where you initialize thousands of
forms?

The video card and whatever offline devices even internet are in my 20%
where parallel processing can be or is useful. I have never denied that.
Although I have not the idea that many visitors here are creating programs
for video cards.

Cor

 

[Cor Ligthert [MVP]]

Peter,

I assume that you are from a country where English is spoken. (I saw it in
your mail header).

However, I assume that you never have worked with large mainframes. I was
using some words from that area, where parallelization is a topic already
for I think about 25 years.

Therefore give me the words you don't understand, than I will change them to
more regular at the moment used PC words.

Beside that I am using consequently Parallelisation instead of
Parallelization. That is standard for somebody from Amsterdam; we don't use
the z or c only the s. Beside that there are more typos. However, I have
never seen that Usenet demands to use correct spelled English in a message.


Cor

 

[Peter Duniho]

[...]
However, I assume that you never have worked with large mainframes. I was
using some words from that area, where parallelization is a topic already
for I think about 25 years.

There's a saying: when you assume something, you make an "ass" out of "u
(you)" and "me".

Don't assume. I have a fair amount of experience with both mainframes and
parallelization. In fact, in the late 80's I spent some time working at
NASA's Goddard Space Flight Center with their VAX/VMS computers and the
MPP computer ("Massively Parallel Processing") that NASA and Goodyear
built.

You may now visit that computer at the National Air & Space Museum's
Udvar-Hazy facility, in Dulles, Virginia.

Granted, that was a SIMD computer, different from the vector
supercomputers and MIMD parallelization best know on the PC side (though
MMX was SIMD, and there are other SIMD implementations on PCs as well).
But my experience with parallelization isn't limited to that work either.

Therefore give me the words you don't understand, than I will change
them to
more regular at the moment used PC words.

It's not an issue of vocabulary. It's the grammar. For example: "I say
parallalisation cost forever procestime". That's meaningless in English,
and I'm unable to convert it something that is meaningful.

Note: I do make an effort to try to figure out what people are writing
even if English isn't their native language. I recognize this is a global
forum, and I see no reason to insist that everyone use English perfectly.
However, for better or worse, English _is_ the standard language here, and
I cannot help it if someone who isn't very good at English hasn't written
something that makes sense in Englih. All I can do is alert them to the
communication barrier and hope that they can rephrase what they wrote, so
that it can be understood.

This is not intended to disparage you or in any way treat your posts
badly. Your English is obviously far better than my Dutch (or whatever).
But it does still need work, and if you are expecting to communicate using
English, you need to be prepared for someone to say, simply, "I'm sorry, I
don't understand".

None of this has anything to do with the technical errors in what you
wrote. As far as I _did_ understand your posts, they were not accurate,
IMHO.

Beside that I am using consequently Parallelisation instead of
Parallelization. That is standard for somebody from Amsterdam; we don't
use
the z or c only the s. Beside that there are more typos. However, I have
never seen that Usenet demands to use correct spelled English in a
message.

I'm not talking about spelling differences. I'm talking about words that
when put next to each other do not construct semantically meaningful
phrases.

Pete

 

[Guest]

Don't assume. I have a fair amount of experience with both mainframes
and parallelization. In fact, in the late 80's I spent some time
working at NASA's Goddard Space Flight Center with their VAX/VMS
computers and the MPP computer ("Massively Parallel Processing") that
NASA and Goodyear built.

Hmm.

Those VAX'es were minicomputers not mainframes.

(the only VAX'es that comes close to be mainframes is the 9000 and
10000 series and the first of those came out in 1990)

And the MPP were a supercomputer not a mainframe.

Arne

 

[Peter Duniho]

Those VAX'es were minicomputers not mainframes.

Ahh...some more pedantry. It's like you can't live without it or
something.

There was nothing "mini" about the VAX computers at that facility and by
the 80's, pretty much anything that didn't didn't fit on a desktop was
often referred to as a "mainframe", at least among the people I was with.
There is nothing about what you might restrict the term "mainframe" to
that was uniquely different from those VAX computers with respect to the
question of parallel processing, nor are those VAX computers the only
"mainframe" computers I have experience with.

What is it with you guys, that you have to negate everything you see? Is
it really that frustrating to not be able to contradict the technical
aspects of the discussion, that you have to look for whatever little nit
you can pick? Even if it means inferring all sorts of things that were
never written or intended?

And the MPP were a supercomputer not a mainframe.

So what? I never even described the MPP as a "mainframe".

Besides, compared to the vector processing supercomputers we also had at
the facility (Cray, Cyber, etc.), the MPP wasn't really even all that
"super". The point is that it was designed _entirely_ for parallel
algorithms, and I did have experience programming it.

Cor made the ridiculous assumption that the problem here was my
inexperience with respect to "mainframe" terminology, and I was simply
pointing out the absurdity of his assumption. How you define the term
"mainframe" is in fact irrelevant...his assumption is asburd regardless,
and the communication problem isn't due to some terminology difference
anyway.

Pete

 

[Guest]

Ahh...some more pedantry. It's like you can't live without it or
something.

Just because you have not gotten some terminology right, then there
are no need that new generations should get the same misunderstandings.

There was nothing "mini" about the VAX computers at that facility

Non the less VAX'es are mini computers. If they were big (6000 and
8000 series) you could call them superminis.

and by
the 80's, pretty much anything that didn't didn't fit on a desktop was
often referred to as a "mainframe", at least among the people I was
with.

There are also people which call the system unit for "hard disk".

That does not make it correct.

What is it with you guys, that you have to negate everything you see?
Is it really that frustrating to not be able to contradict the technical
aspects of the discussion, that you have to look for whatever little nit
you can pick? Even if it means inferring all sorts of things that were
never written or intended?

Actually minicomputer and mainframe are technical terms.

Your focus on the english language on the other hand ...

Arne

 

[Peter Duniho]

Actually minicomputer and mainframe are technical terms.

Bull. They were/are marketing terms. The primary thing that
distinguishes a "mainframe" from a "minicomputer" is their relative
physical size, which is hardly a "technical" attribute.

Your focus on the english language on the other hand ...

My "focus on the english language" pertains only to the fact that I have
no way of understanding what a particular post was meant to say. I am
not, unlike certain people around here, trying to make a disagreement just
for the sake of disagreement. I am trying to help the person understand
that whatever point he is trying to make has simply gone uncommunicated,
due to the grammatical problems with the post.

Pete

 

[Cor Ligthert [MVP]]

Alex,

By the way, I think that you are more talking about what started as
multiprogramming. Something I did already long ago on mainframes. I did it
with datacomm work too, but to show what I mean, I write bellow the most
simple batch process as sample.

You read a tape and put that in a queue.
In the same time you process the queue.
In the same time you print the results from the queue.

The first will end very much before the second and mostly the third takes
the most time, however it shorten the throughput only a little bit. (Because
of that the sum of the processes was mostly not much longer than the
printing time).

That is just easy. But that is for me no parallel processing. In a parallel
process they end all at almost the same time.

To explain better what I mean to by instance Pete this Wikepedia page.

http://en.wikipedia.org/wiki/Multiprogramming

Cor

 

[Jon Skeet [C# MVP]]

Alex,

By the way, I think that you are more talking about what started as
multiprogramming. Something I did already long ago on mainframes. I did it
with datacomm work too, but to show what I mean, I write bellow the most
simple batch process as sample.

You read a tape and put that in a queue.
In the same time you process the queue.
In the same time you print the results from the queue.

The first will end very much before the second and mostly the third takes
the most time, however it shorten the throughput only a little bit. (Because
of that the sum of the processes was mostly not much longer than the
printing time).

That is just easy. But that is for me no parallel processing. In a parallel
process they end all at almost the same time.

So unless the processes all end at almost the same time there is no
parallel processing? That sounds like a silly definition to me.

There is only parallelism while more than one thing is happening at
once, of course - while, for instance, the tape is being read *and*
the queue is being processed at the same time. Even if that only
happens for part of the time, during that phase it's parallel
processing.

Jon