Major concerns regarding Trainz background processes

I've noticed that as well. TrainzUtil also crops up sometimes as well.

It reinforces my feelings that the background processes need a re-write.

Shane
 
Longest delay I see in changing tabs in TS12 is about 1 or 2 seconds and only on the first access of that tab, I think down to caching, which is on the system drive, not the Trainz one, SSD's on both so probably why I'm not getting a problem.
 
Longest delay I see in changing tabs in TS12 is about 1 or 2 seconds and only on the first access of that tab, I think down to caching, which is on the system drive, not the Trainz one, SSD's on both so probably why I'm not getting a problem.

Sometimes I get massive delays in changing the tabs in CMP.... Like sometimes up to 5 minutes or more..
 
Not related to auto save, that was the first thing I disabled since it was the most likely suspect. Also not related to ichat, same alibi, disabled, wasn't even in town Other thing besides switching tabs - edit session rules or click on a loco/car with the question mark to add running number or load, question mark click on a portal or industry to configure, always freezes for a minute or two if it's the first time you used that since you started the game. It's caching something tho, because you do the next portal - car - loco - session rule edit and it loads right away, it's only the first time after restarting the game that it does it. Which is also intermittent, sometimes you do it the first time that day and there's no pause at all.
 
The "Question Mark Freeze" is simply the game initializing the internal editor. Once it is initialized, it is 'in-game' and can be called upon instantly. it is about the only thing the game dies right: don't load anything you don't need until called for.

I have a feeling that if the databse is only accessed ONCE and held in memory, then TADDaemon and/or TrainzUtil won't have to keep re-loading the database and that entails. After all, how can you import a new CDP (and cause the database to be updated) while you are in Surveyor - you can't, so why do you have to keep re-loading the database?

Bill
 
Last edited:
When in Surveyor, you can probably hang the hesitations to the Auro-Save "feature". To verify this, go into the options and change the auto-save interval. If the time between hangups increases (or decreases, depending on which way you went), then you've found your culprit.

I have a feeling that somehow the Auto-Save is involved also in Driver, possibly to save the current Session in case you want to exit.

Bill

Thanks, I should have mentioned that I disabled Auto-Save long ago.
 
The "Question Mark Freeze" is simply the game initializing the internal editor. Once it is initialized, it is 'in-game' and can be called upon instantly. it is about the only thing the game dies right: don't load anything you don't need until called for.

I have a feeling that if the databse is only accessed ONCE and held in memory, then TADDaemon and/or TrainzUtil won't have to keep re-loading the database and that entails. After all, how can you import a new CDP (and cause the database to be updated) while you are in Surveyor - you can't, so why do you have to keep re-loading the database?

Bill

I think you've hit on something here. I've noticed that too, and with more RAM the better it will run because there's more room for both the application and the database. I noticed very little disk access after putting in 16GB of RAM in my PC.

John
 
Right, John. When I moved my game from my 32-bit/3G RAM machine over to my new 64-bit/8GB RAM machine, I noticed a HUGE improvement in performance. Granted, the upgrade in processor and all that probably had a lot to do with it, but when I ran Task Manager alongside Trainz, I found that on the smaller system, there was a lot of memory growing/shrinking when I started the editor. On the bigger system, the memory only grew a bit when I accessed the editor.

It is my belief that for some reason the entire database is NOT kept available in RAM. It is accessed, sometimes with a completely clean "Select from..." statement, so that would account for the delay in opening the Content, Textures, and other tabs.

EDIT: And, as for the hesitations and such, I've noticed that they almost always are in conjunction with a lot of disk access.

Bill
 
Disk access also wouldn't apply here, running off a solid state drive. Trainz.exe uses about 100 to a max of 600 megs of RAM depending, TADDaemon uses about 140 to 160 megs. Got the minimum spec 1 gig that could be an issue, but with 2 gigs or more RAM I don't see how memory would be a problem, especially if your system is configured for games with all the useless processes disabled from services.

"The "Question Mark Freeze" is simply the game initializing the internal editor. Once it is initialized, it is 'in-game' and can be called upon instantly."

That was my initial assumption, question then is why it does it sometimes the first time and sometimes it doesn't the first time? Same with session rules, sometimes start TS2010, create new session, click edit session rules and look at an hourglass for 2 minutes. Reboot the system and repeat, session rules load instantly. Reboot repeat, 1 to 2 minute wait while it thinks about whatever it's thinking about until it loads the session rules screen. Same thing 5 times in a row, then the sixth time it loads instantly. No consistency or logic I can find in any of it.
 
Right, John. When I moved my game from my 32-bit/3G RAM machine over to my new 64-bit/8GB RAM machine, I noticed a HUGE improvement in performance. Granted, the upgrade in processor and all that probably had a lot to do with it, but when I ran Task Manager alongside Trainz, I found that on the smaller system, there was a lot of memory growing/shrinking when I started the editor. On the bigger system, the memory only grew a bit when I accessed the editor.

It is my belief that for some reason the entire database is NOT kept available in RAM. It is accessed, sometimes with a completely clean "Select from..." statement, so that would account for the delay in opening the Content, Textures, and other tabs.

EDIT: And, as for the hesitations and such, I've noticed that they almost always are in conjunction with a lot of disk access.

Bill

The change in tabs most likely means a change in that part of the database being indexed so those items have to loaded into RAM. I would think that it would be nearly impossible to load 120-Plus GB of assets into memory. I've noticed on regular hard drives that a good defrag really helps, and so does doing a Quick Database Repair. The defrag is speeding up the disk access some, and the latter function is re-indexing, making the loading process faster.

I saw the other night that we're actually running SQL-Lite, or a subset of the functions to access the data. I saw this when I opened the crash.dmp file in WinDBG. The merge error is another interesting bug in itself, which I'll explain later. It's nothing we can fix or get around easily.

John
 
Hmmm. Even with a SSD, there would be 'disk access' I think. The indicator LED might not be fast enough to display the state change, but I bet it's there. How about the Resource Monitor in the Task Manager? Does it show anything on the Disk tab?

I have always had the Question mark freeze - no exception. The first time I use it, I get the freeze. I don't do a lot of sessions so I wouldn't know about them.

I think the big factor here is that we are still just guessing about things. Nobody from N3V is going to "give away secrets" and tell us how they handle RAM or Disk access so all the guessing we do is still theoretical. We may have a load of experience between us, but it is still nailing jelly to a tree otherwise.

Bill
 
@John: I guess I should have made my statement a little more specific. When I said 'database' I actually meant a sub-set for the route that is being worked on. For most cases, that could be held in RAM. When a new Function tab (right side) is opened, then the whole database has to be re-polled for content and the INDEX could be held in RAM. But, it takes time to create that index, and the more content you have, the longer it takes. I have a virgin copy of TS2010 that I use for testing. As soon as the item is tested, i delete everything I loaded up specifically for that route. That way, the database stays lean and mean. I still get delays though.

Bill
 
@John: I guess I should have made my statement a little more specific. When I said 'database' I actually meant a sub-set for the route that is being worked on. For most cases, that could be held in RAM. When a new Function tab (right side) is opened, then the whole database has to be re-polled for content and the INDEX could be held in RAM. But, it takes time to create that index, and the more content you have, the longer it takes. I have a virgin copy of TS2010 that I use for testing. As soon as the item is tested, i delete everything I loaded up specifically for that route. That way, the database stays lean and mean. I still get delays though.

Bill

I understand exactly what you're saying. I just didn't type my response the way I should have. The Assets.tdx is the database file. This is a single, flat file, database instead of a relational, multi-table, database. This would make sense and proves exactly what we're thinking because if there's a ton of stuff, then the database has to be reloaded back in again and re-indexed again and again for each tab and category. I noticed too that this becomes more of an issue if I've downloaded stuff off of the DLS then go into Trainz. The new stuff takes some time to settle into the program so the first the category tabs are accessed, the process will be a bit longer than usual.

Perhaps if in some future version of Trainz, they'll have a database container containing multiple tables with each table being the different content categories, tabs, etc. Perhaps Assets.tdx is already like that but poorly implemented. We really don't know and speculation is fun. I agree it is like trying to nail jelly to a tree.

John
 
All my programs that use a database are definitely relational databases. For a long time, I used MDB files because they could be used either with my own programs or quickly accessed with Access for checking things out. I definitely agree that multiple tables with relationships spelled out in rules are the only way to go.

I think we've beat this subject to death here though. Not much else to discuss. Surprisingly, nobody from N3V has popped in to tell us how right or wrong we are.

Bill
 
Actually it was dead before this thread started, I asked if they could straighten out the track a bit and the consensus was that the track didn't need to be straightened, I just needed to get a machine that can handle sharp curves.

486933_566744423342957_1807030778_n.jpg
 
I like your image there Jim.

Meanwhile, I will keep trying to get N3V to sort out their bugs one step at a time. (probably needs Pest Control...)

Shane
 
It does depend on when it happens. I have heard of reports of pauses when changing tabs, which can be attributed to TADDaemon.

Shane

For me, I only see the pause once and only on certain tabs.
Tabs it happens on: Ground Textures, Buildings/Splines, Rolling Stock/Consists
Tabs it does NOT happen on: Terrain/Water, Tools
Don't remember about the Track tab. I had the same thing in TS2009 but only with the Ground Textures tab, I figured it was all the images loading in the list.

I also get pauses whenever I type something into the Search Filter, it pauses before changing any lists.
 
...

I also get pauses whenever I type something into the Search Filter, it pauses before changing any lists.

Yup. I forgot about that. I get long pauses every time I type anything in the Search Filter at the top of my Textures flyout. My typing will sometimes not show up for ten seconds after I quit typing. If I have to alter the search text, that takes just as long also. Usually what happens is that I hit the Backspace key a few times to clear out a few letters and end up hitting it too many times and have to start over. Very disconcerting to say the least.

Bill
 
Back
Top