Apart from clock_gettime() not being available on Windows, the manpage states that it will not work properly on Multicors. Thus I think the time(NULL) should be rather kept.
The problem is, that time(NULL) returns seconds and not milliseconds. I searched the internet and there seems to be no posix way to get milliseconds...
Quote
Moreover, I want to do profiling without fast forward (for instance on graphic updates). Thus I took out the mandantory fast forward for profiling. The second ifdef is also not needed, since you will use profiling usually with a loaded game. Anyway, looking for quit_month seems a wiser choice here.
Coupling the fast forward to the "until" is a good choice!
Am still on the 2009-11-02 version, as there are no later Linux binaries, but I have been seeing this for awhile. The train report lists separate cargos in the wrong place, even though the "consist" report shows the cars (carriages) properly loaded.
This bug should be fixed in r2576, which should be incorporated in exp...
Ok. But we should do it step-by-step. Here's a roadmap:
1. simconvoi_t::get_catg_index (maybe sorted). Or what about a bit-field: vector_tpl<bool> enabled_catg_index(length: max_index_catg); enabled_catg_index[ i ] == true <=> catg_index i can be transported by convoy => Then the same for lines
2. stations keeping track of their lineless convoys
2.5. Optimize rebuild_destinations
3. local schedule_counter, global reroute counter.
3.5. Optimize reroute_goods
If it is ok, I will do this in the next weeks (months, years, centuries,...)
I thought of a variable simconvoi_t::add_catg_index_is_dirty and every time a vehicle changes, this is set to false. If now get_add_catg_index is called and it is dirty, it is recalculated. With this you have almost none overhead (and then you won't need doubled code ).
Some code doubling is better, since the gathering of the goods of lineless convoi take some time. This is especially true, if then the owner is wrong or the convoi does not stops at the own stop. Based on your patch, this would be my suggestion.
Argh, I don't like to view a diff of patches
Ok, my notes: - I would like to use an uint32 to index the convoys rather than this iterator beast - at least for me it is a beast... - The convoys could cache the catg_index-vector. This would take a little bit memory, but saves comp. time. - If the stations also have a list of lineless convoys, we could save even more comp. time (I've done this successfully some time ago). Also players would benefit from this, if this list is displayed at the stations details.
Can you commit your suggestion, so we have a common basis for the next suggestions? (The patches would become smaller and easier to read).
Quote
(And the iterator require preincrement, although for vectors this is not enforced by the code. Also I dislike *xyz->operator[](inxed) compared to (*xyz)[index]. Is there a reason which using the long code?)
No, it's only personal preference - I don't like the (*xyz)[idx]
Btw, formerly bound handles could be treated easily as not equal, since their ids differ!
Yes.
Quote
However this would break code in some places, I fear. And I see no gain, unbound should be unbound.
Mmh. My idea was, that two unbound handles are always unequal (even if they have the same "entry"). Currently, unbound handles are "sometimes" equal and sometimes not. This is somehow inconsistent, but equality of unbound handles isn't tested often in the game, I think. And since the bug is fixed in r2850, we don't have to touch this (yet).
Maybe get_halt() returned halthandle_t() and they made a big group.
Oh, yes. This is it: On loading, all ware_t gets a unique halthandle_t (this can get unbound after loading). But, if get_halt return halthandle_t(), all those ware_t have a handle with entry=0. And then the ==operator returns true. And then pax and mail gets joined...
Maybe we should think of halthandle_t()!=halthandle_t()? Matlab (a program for numerics), e.g., has NotANumber!=NotANumber. Maybe this is also usefull here.
Make the bags by stops would make the test for already existing connections with lower stops count a little longer. SO I did not do this.
But if you have the bags, and you want to search for a warenziel_sorter_t with a small "stop", you have to look only in the bags with small numbers (< stop). I would guess, it could be a little bit faster.
With this patch you are able to build a tunnel without building a way on the slope first. The tunnel will also auto-connect to ways laying in front of it.
Any sorting routing would do essentially the same than this loop. There is no gain only looks prettier.
Shouldn't it be faster to sort it first (or keep it sorted all the time)? Or you make one basket for every value of warenzielsorter_t::stops?
Quote
I was aware that shorter lines may add non_identical_schedules. But on the other hand this routine is very time critical. Therefore I omitted this extra check if there is a longer match.
Yep. But I think, I was also wrong - only Knightly was right
But I think, the routine has a problem, discussed some time ago: If you have 100 packets, 1-98 are unfeasible, 99-100 are feasible. Then the first feasible packet has a chance of 99/100 and the other only 1/100.
However, I had the idea of sorting the simhalt_t::waren[] with respect to the next transfer stop. This would also speedup some routines (especially the hole_ab). Do you think it's a good idea?
Edit: I've read the thread again - at least you thought it's a good idea
In line 1091 "!warenziele_by_stops.is_contained(wzs)" is true also, if the connection is already there, but the existent is longer. But then, one don't need to increase "non_identical_schedules".
2nd: And imho, it would be better in line 1160-1174 to sort the warenziele_by_stops by the stops variable rather than do this double loop.
3rd: Wouldn't it be better to do the stuff for the lines before the single convoys? Then lines would be preferred since they usually have the higher throughput.
4th: I would also prefer not to double the code in lines 1051-1104 and 1128-1154.
Sometimes I think it would be better if not the whole map is rotated, but only the display routines consider the rotation. Of course, this would require big changes...
