Re: [Rails-devel] Improved revenue prediction / different scenario

[alexti <al...@sh...>]

Hi Stefan,

> Memory management should be irrelevant for the Java program, as all  
> variables
> involved are fixed sized arrays, which are defined as final.
I am curious, how do you avoid dynamic memory allocation during the  
iteration through the routes? With the switch to the two-phased approach I  
also couldn't avoid some dynamic sizing in the second phase graph.


>> What exactly 5,651k predictions in your case mean?
>
> Evaluations count the call to the function that sums up the value of all
> trains after all trains are finished.
Can you tell from this number how many times revenue of the route has been  
computed?

> Predictions count the call to the function used after each station visit.
>
> Actually the latest refactoring (I do not evaluate anymore until I reach  
> the
> second station, previously I set that to zero) reduced the number of
> evaluations and predictions:
> The number of evaluations drops to 480k, the number of predictions to
> 2,950k, the number of edges travelled does not change.
> Speed improvement is minor (10-15%).
This sounds like what I was calling revenue of the route computation. Is  
it the place were you total value of cities and apply bonuses?

> I have an outer loop that iterates over the base tokens: After I have
> considered all routes from the first token, I keep that vertex as  
> visited to
> avoid evaluating the identical route again. (All routes with both first  
> and
> another start token are already found from the first route, this will  
> work as
> long as connectivity is symmetric).
Yeah, we have the same approach here (aside of marking vertex vs edge).

Alex.