I'm facing a situation like there are about more than 1k instances of a class, where a method of the class should be called frequently. Since the current implementation is through maintaining a list of the instances and calling the method using a for loop and it hurts the real-time requirement of the application, I'm considering the signal and slot mechanism from Qt.
The question is: if i change the method into a slot and connect it with a signal while the instance got created, and instead of calling the method through a for loop, i emit a signal. Will it be faster than the for-loop solution?
The short answer: No.
Long answer: You should try and measure it yourself. But I bet that calling a function directly is definitely faster than signal-slot invocation. Why? Because signals and slots are no magic. They are also just function calls but with lots of extra overhead.
Which one should I use? For more context I use redux-toolkit. Advices to help understand which tool fits better are appreciated
The Redux Styleguide very clearly recommends thunks over slices for most asynchronous logic. If you have very complex and intertwined logic, sagas might make sense, but most applications don't have that kind of logic.
Also, you should probably try out using RTK-Query which would reduce your need for either middleware for asynchronous tasks quite a bit.
I already know when calling an asynchronous method e.g. myAsync(), the caller e.g. Caller() can continue executing without waiting for it to be finished. But on the other hand, myAsync() also is executing.
public void Caller(){
myAsync();---------------------running
dosometing();------------------running
}
The code next to myAsync() in Caller() will execute with myAsync() at the same time. So could this situation be considered as a kind of concurrency?
update
I prefer use javascript and c#
That very much depends on the concurrency model of your programming language.
If your language allows you to define methods that are "implicitly" running in parallel; then of course, calling myAsync() would use some kind of "concurrency mechanism" (for example a thread) to do whatever that method is supposed to do.
In that sense, the answer to your question is yes. But it might be important to point out that many "common" programming languages (such as Java) would only "work" in such a context when myAsync() would be creating some thread to then run "something" using that thread.
I have callbacks implements in my unity3d game in such a way that they are all nested,i.e. one callback leads to another call, whose callback leads to another call and so on upto 5 times. But the last two callbacks are losing their order. Before the second last delegate finishes execution, the last one gets executed! I am using delegates as means of message transfer (other way could be to implement interfaces). Do delegates in C# behave asynchronously by any chance? Implementin callbacks using delegates and using interfaces should yield the same results everytime, correct? And both are synchronous? Any lead on the issue would be greatly helpful.
Thanks
Depending on how you're using delegates the invocation order could not be specified.
See: Whats is the difference between nested method call and delegates?
The docs for flash.utils.setTimeout() state:
Instead of using this method, consider
creating a Timer object, with the
specified interval, using 1 as the
repeatCount parameter (which sets the
timer to run only once).
Does anyone know if there is a (significant) advantage in doing so? Using setTimeout is a lot easier when you only need to delay 1 call.
setTimeout actually uses a Timer subclass, the SetIntervalTimer, which is an internal class. You can check by doing setTimeout(function ():void { throw "booom"; }, 1);. You'll see it in the stack trace.
As such, I cannot really see a big disadvantage. The only difference is, that you have 2 anonymous calls instead of one. OTOH, in performance critical situations, you shouldn't be using either (except one internal timer) to avoid frequent instantiation of TimerEvent objects.
Basically, I think it's a matter of taste. Adobe decided, the AS3 event system is the shizzle, so they promote it.
Timer:
Gives you more control as you can
register more event listeners to
receive the event rather than a
single one with setTimeout
You can control the start time and
the number of repetitions ( not very
useful against setTimeout, as this
has to run just once and after a
delay considering the immediate time
it was called)
More lines to write, even more if you
need to differentiate with parameters
( custom event class for this )
Use of event listeners which is
standard practice in as3.
Cleaner look
setTimeout:
Easier to use
Less code to write
Parameters can be easily sent;
I prefer the Timer class but I've seen setTimeout being frequently used by programmers.
Also if you are using Tweening libraries,some support delayed call
For example TweenMax
TweenMax.delayedCall(2, myFunction, ["myParam"]);
For all those who say that setTimeout is deprecated, this is non sense..
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/utils/package.html#setTimeout%28%29
I believe you can't see any "deprecated" keyword around setTimeout here
setTimeout is working perfectly well in external .as files.
Just use this in the class :
import flash.utils.*;
import flash.events.TimerEvent;
It's my understanding that setTimeout is depreciated in AS3. I'm having a bit of trouble finding the source of the setTimeout code, but I also believe it's easier to clear up any references to the Timer object, than with setTimeout (if I remember correctly from AS2).
Usually something becomes deprecated if there becomes new and more powerful way to achieve something.
Yes setTimeout is much more easier to setup in some cases, but it is much more limited in other cases.
I would use the Timer class, because usually when something is deprecated, it means support may be removed for it sometime in the future, and then your code won't work.
The problem is, the Timer object is not at all accurate, and is subject to framerate fluctuations. Read http://forums.adobe.com/message/892631. I created my own Timer (called RealTimer) using the Date object and it is much more accurate. I recommend doing the same.
setTimeout is not working in external .as files.