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

[Stefan F. (web.de) <ste...@we...>]

Hi Alex,
answers/comments see below.
Most of them delay a more detailed discussion for the time after the current 
release.
Stefan

> Oh, I see. That essentially means that you're using stack as a way to
> dynamically allocate memory. It probably means that function inlining is
> not working and the actual overhead may show up as a function call
> overhead. Anyway, that's something to look at in the profiler. I was
> hoping you've found some algorithm that was avoiding the need for dynamic
> memory management.
>

In principle I could replace the reliance on the java stack mechanism by 
storing the local variables in own stack. The next step would be to remove 
all recursive function calls, but I have doubts that this will improve the 
speed substantially, if at all. I plan to install the TPFP plugin after this 
release to get some data on that.

> > The scenarios where it excels compared to revenue predictions are those
> > in
> > which you cannot run the trains to the full length.
>
> I am not sure about that... If the optimal route set is achieved on 4+5
> routes, it wouldn't matter which one is served by 8 train and which one is
> by 10. I think it would only make difference on such scenarios where the
> optimal route sets contains routes that have length between the length of
> the trains (for example 6+9 routes for 8+10 trains).
>

I was more referring that the revenue prediction improves with the train run 
lengths in general, not that train dominance is better in those cases.

The good thing about revenue prediction is that if the network increases it 
gets less likely that the trains runs are short. It is very unlikely for a 
company to have a complex network AND not being able to run its trains for a 
good length.

>
> No :-) But I can't find anything missing in my implementation. I wonder if
> we either misunderstand what each other counts or someones counting is
> wrong (though mine matching function call count shown by the profiler :) )

For the next release I plan to include the two-phase approach, this should 
ease comparisons.
>
>
> Alex.
>
> ---------------------------------------------------------------------------
>---
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel