For example, I need a timer on the page. So I can have an action every 100 ms
type Action = Tick Time
and I have field time in my Model. Model could be big, but I need to recreate it and whole view every 100 ms because of time field. I think it would not be effective performance-wise.
Is there another approach or I shouldn't worry about such thing?
The whole view isn't necessarily being recreated every time. Elm uses a Virtual DOM and does diffs to change only the bare minimum of the actual DOM. If large parts of your view are actually changing on every 100ms tick, then that could obviously cause problems, but I'm guessing you're only making smaller adjustments at every 100ms, and you probably have nothing to worry about. Take a look at your developer tools to see the whether the process utilization is spiking.
Your model isn't being recreated every 100ms either. There are optimizations around the underlying data structures (see this related conversation about foldp internals) that let you think in terms of immutability and pureness, but are optimized under the hood.
Related
If real time planning and daemon mode is enabled, when an update or addition of planning entity is to be made a problem fact change must be invoked.
So let say the average rate of change will be 1/sec, so for every second a problem fact change must be called resulting to restarting the solver every second.
Do we just invoke or schedule a problem fact change every second resulting to restarting the solver every second or if we know that there will be huge amount of changes, stop the solver first, apply changes then start the solver?
In the scenario you describe, the solver will be likely restarted every time. It's not a complete restart as if you just call the Solver.solve() with the updated last known solution, but the ScoreDirector, a component responsible for score calculation, is restarted each time a problem change is applied.
If problem changes come faster, they might be processed in a batch. The solver checks problem changes between the evaluation of individual moves, so if multiple changes come before the solver finishes the evaluation of the current move, they are all applied and the solver restarts just once. In the opposite case, when there are seldom changes coming, the restart doesn't matter much, as there is enough time for the solver to improve the solution.
But the rate of 1 change/sec will likely lead to frequent solver restarts and will affect its ability to produce better solutions.
The solver does not know if there is going to be a bigger amount of changes in the next second. The current behavior may be improved by processing the problem changes periodically in a predefined time interval rather than between move evaluations.
Of course, the periodic grouping of problem changes can be done outside the solver as well.
As i can understand from the documentation the purpose of the "MoveIteratorFactory" is to generate the moves as they are needed to be played out at every step.
Is the "getSize" method how big the subset of moves will be?
What is the difference between "createOriginalMoveIterator" and "createRandomMoveIterator"?
Will the "createOriginalMoveIterator" regenerate a subset of moves again in a later step or not?
I guess that the move is played out after the method next() is called (after its creation) in both the cases?
Is this the best solution if there are a lot moves that need to be generated ,because in my case there are many moves that need to be first of all generated let alone played out?
Is there a smarter way to generate custom combined moves at every step that are based on the current state of the solution?
The MoveIteratorFactory is a more complex alternative to MoveListFactory which avoids creating a List<Move> by creating an Iterator<Move> instead. In Java 8 terms, it has a lot in common with a Stream.
Suppose you have 50k entities and 10k values. A list of all changemoves would contain 500m elements, causing memory issues and a serious delay loss every time a step starts. To avoid that, it generates a changemove just in time, at Iterator.next() or hasNext().
For that to work well, it needs to behave differently if the iterator needs to selects moves randomly (= might select the same move twice, this is not shuffled, it's random!) or original order.
Suppose you have 50k entities and 10k values. A list of all changemoves would contain 500m elements, causing memory issues and a serious delay loss every time a step starts. To avoid that, it generates a changemove just in time, at Iterator.next() or hasNext()
I'm working on an IRC bot in VB.net 2012. I know I know, but it's not a botnet, lol
I wanted to ask your advise on how to manage to many timers. Right now I have a timer that rewards points at a user specified interval, a timer that autosaves those points at a user specified interval. I also have one that displays advertisements, and broadcast a collection of responses at specified intervals.
I feel like it's getting out of hand and would love to know if there is a way I could do all of these thing with a single or at least less timers.
Please keep in mind I learn as I go and don't always understand all the terminology, but I am a quick learner if you have the patience to explain. :)
Thank you.
Yes, of course you can do them with a single timer. In fact, that is what you should do—timers are a limited resource, and there's hardly ever a reason for a single application to use more than one of them.
What you do is create a single timer that ticks at the most frequent interval required by all of your logic. Then, inside of that timer's Tick event handler, you set/check flags that indicate how much time has elapsed. Depending on which interval has expired, you perform the appropriate action and update the state of the flags. By "flags", I mean module-level variables that keep track of the various intervals you want to track—the ones you're tracking now with different timers.
It is roughly the same way that you keep track of time using a clock. You don't use separate clocks for every task you want to time, you use a single clock that ticks every second. You operate off of displacements from this tick—60 of these ticks is 1 minute, 3600 of these ticks is 1 hour, etc.
However, I strongly recommend figuring out a way to do as many of these things as possible in response to events, rather than at regular intervals tracked by a timer. You could, for example, reward points in response to specific user actions. This type of polling is very resource-intensive and rarely the best solution.
I am automating a form, which has many fields all of which are dynamic, i.e. fields are generated on basis of value selected in preceding field. At present I am waiting for each field, if it appears I fill it, otherwise I skip it. However, this has made the process very slow. Is there a more efficient way to do it?
As suggested by Vinay you can reduce certain amount of execution time but not entirely.
Does it not take time when you are testing it manually? If the total execution time for the scenario is taking more time than doing manually then this scenario is not a good candidate for automation. But if the time taken is less than doing manually then it is still worth spending.
It depends upon the application speed. when you are able to do it in manual.It's possible in Automation too.We could reset the implicit wait time to speed up the process.
driver.manage().timeouts().implicitlyWait(0,TimeUnit.SECONDS);
Dont forget to set the time to use it again.
I know about runtime code execution fundamentals in Flash Player and Air Debugger. But I want to know how Timer code execution is done.
Would it be better to use Timer rather than enterFrame event for similar actions? Which one is better to maximize optimization?
It depends on what you want to use it for. Most will vehemently say to use Event.ENTER_FRAME. In most instances, this is what you want. It will only be called once every frame begins construction. If your app is running at 24fps (the default), that code will run once every 41.7ms, assuming no dropped frames. For almost all GUI related cases, you do not want to run that code more often than this because it is entirely unnecessary (you can run it more often, sure, but it won't do any good since the screen is only updated that often).
There are times when you need code to run more often, however, mostly in non-GUI related cases. This can range from a systems check that needs to happen in the background to something that needs to be absolutely precise, such as an object that needs to be displayed/updated on an exact interval (Timer is accurate to the ms, I believe, whereas ENTER_FRAME is only accurate to the 1000/framerate ms).
In the end, it doesn't make much sense to use Timer for anything less than ENTER_FRAME would be called. Any more than that and you risk dropping frames. ENTER_FRAME is ideal for nearly everything graphics related, other than making something appear/update at a precise time. And even then, you should use ENTER_FRAME as well since it would only be rendered in the next frame anyway.
You need to evaluate each situation on a case-by-case basis and determine which is best for that particular situation because there is no best answer for all cases.
EDIT
I threw together a quick test app to see when Timer fires. Framerate is 24fps (42ms) and I set the timer to run every 10ms. Here is a selection of times it ran at.
2121
2137
2154
2171
2188
2203
2221
2237
As you can see, it is running every 15-18ms instead of the 10ms I wanted it to. I also tested 20ms, 100ms, 200ms, and 1000ms. In the end, each one fired within about 10ms of when it should have. So this is not nearly as precise as I had originally thought it was.