Make a program faster if a line/method takes long to complete

Question

0.00/5 (No votes)

See more:

So I have an event that does some processing and one of the lines in the event takes a long time to complete thus the stuff that happens in the event, very undesireably.

Is it common practice to separate out the thing that takes long (in this case it is a a line of code that calls a method that takes a long time) in the form of a thread?

For example, maybe I can have a boolean that can then be detected by the thread that continuously checks for this boolean. Or is there a more elegant way of approaching the problem?

What I have tried:

I have one event that runs a block of code, but there is a bottleneck at a time-consuming line of code.

Posted 27-Dec-21 15:07pm

Admin BTA

Updated 27-Dec-21 17:54pm

Add a Solution

Comments

PIEBALDconsult 28-Dec-21 16:20pm

Yes.

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

k5054 · Answer 1 · 2021-12-27T17:54:00

That largely depends on what else is going on in you program. For example, lets assume that the time-consuming code (TCC) takes 90% of the time needed for the procedure to complete. Handing that section off to a separate thread isn't going to make a great deal of difference to the overall runtime for the procedure. If, on the other hand, the time consuming code takes about 50% of the time needed, you should see a speed-up factor of about 2. That assumes that there's no inter-dependence between the critical section and the rest of the procedure. If the procedure needs the results of the TCC to proceed, then shipping that off to a separate thread won't improve things either.

Adding threads may make things worse. If the thread and the "main" procedure need to coordinate data access to shared variables, then the overhead of creating, acquiring and releasing mutexes might cause a severe negative impact on the overall runtime.

On the other hand, if the TCC is a good candidate for parallelization, then that might be the improve things greatly. E.G. if the calculation is some sort of loop, for which each pass uses a set of data that's independent from any other loop, then you might see great gains.

The best place to start though, is to examine the code in question. Is there another algorithm that will give the same results but at a lower cost? For example, if you need to sort your data, how efficient is your sort? If you're using a good sort, are you inadvertently triggering worst-case behavior? If you're using a collection which needs to be traversed, can a different collection provide better performance? Or is there a different traversal technique that will use less time? Will sorting the collection improve things? Maybe you're doing something that's artificially slowing things down when you don't need to, like forcing a data flush to disk on every I/O operation, when you might be able to get away with one data flush at the end of the calculation? There are many things that could be causing things to be slow. Analyze your code, and see if there's improvements that can be made before resorting to threads.