There is a utility in Windows called perfmon if you have a search through the forum you may come across the results that were obtained monitoring performance whilst Trainz was running. There were very few disk accesses whilst it was running. This was done some time ago.
I forget which version of trainz it was but essentially once Trainz has read the disk files in the hard disk performance shouldn't matter that much.
Having said that for some large layouts the initial read is a fair chunk of data. Also latency appears to be important.
James_Moody or Bloodnok wrote this 15 months ago in Trainzdev on hardware performance it maybe of interest:
"It's important when discussing this to make a distinction between what works best with "classic" trainz (e.g. 2004, 2006, the Trainz Classics series, etc, etc), and 2009. Experience with 2004 and 2006 is not necessarily valid in 2009, however, some of it will be.
My experience of 2004 and TC3 says RAM is key.
Trainz is memory hungry. The S&C (from TC3) will make trainz use over 1GB all by itself. Bigger route == more RAM. More detail == more RAM. This is unlikely to change for 2009.
Trainz is a 32 bit process, so can use up to 2GB on it's own. The important point here, is that this is in addition to anything the OS is using (e.g. for disk cache). With a 32 bit OS, you'll hit a limit at about 3GB - 3.5GB depending on hardware config. With a 64 bit OS, you can go further (but Trainz will still be limited to 2GB in it's own process).
After system memory, comes dedicated graphics card RAM. The speed of the GPU isn't so important (see later note) - more the amount of memory it comes with. (Oh, and don't, under any circumstances, share RAM. That is a quick way to appalling performance).
After RAM, disk performance is next. Putting a 10000RPM SATA Raptor (150GB version) in my home desktop made a huge difference to Trainz. (Interestingly, setting up two 7200RPM SATA disks in RAID0 didn't. It seems to me to be latency that is the primary issue, not the overall transfer speed - and RAID does very little to improve latency when used by a single program.)
As far as multiple cores goes - Trainz is multithreaded - but there is a lot that runs in the main thread that is not threaded, and can't be easily made threaded. Over time, more threads are added. TRS2004 had threads, but didn't do all that much in them. TRS2006 improved the threading significantly. As of TC3, Trainz will use a dual core processor fairly well, but you're unlikely to get much additional benefit from a quad core. If the choice is between a fast dual core processor, and a quad core which while faster overall has individually slower cores, I'd take the dual. 2009 may well have a bit of additional threading - but it's going to be an evolutionary step, not a revolutionary step. I'd still take the dual for 2009 as well.
It is true that 'classic' versions of Trainz don't benefit all that much from the fastest graphics cards - mid-range cards perform surprisingly well compared to the top of the line versions. This is mainly down to usage, and is expected to change for 2009 - at least when 2009 spec content is in use.
All other things being equal (and assuming enough system bandwidth to do this without hitting another problem...) if you double performance of the graphics card, and double the polycount of each object on display, it should come out at about the same framerate. i.e. if you had 10 x 50-poly houses before, you now have 10 x 100 poly houses, and with twice the graphics card grunt, you're running at the same framerate.
Extrapolate that out from version 1.0, and you can begin to see what maps "should" look like for high performance in current versions - i.e. very few objects, but each one highly detailed. But that's not what people do. They try to double the number of objects each time. And that's where Trainz doesn't scale. For example - in TC3 and earlier, making a housing estate by placing the same low poly house 50 times in surveyor will be far slower than cloning that house 50 times in 3DSMax and exporting the resultant estate as one object to place in surveyor. The reason for this, is that trainz gives the placed objects to the graphics card one at a time. And if the creator used one texture for the roof, another for the walls, and a third for the windows and doors, Trainz will give each of these pieces to the card separately too. Thus the one 2500 poly housing estate (which is given to the graphics card in only a small number of calls) will render a lot faster than 50 identical 50 poly houses (which will be at least 50 separate calls).
In 2009, for most assets, many instances of the same asset will be drawn with one call. So your 50 identical 50 poly houses should now render a LOT faster than they did before - essentially the same speed as the one 2500 poly housing estate, in fact. Combine this over all the assets you place, (and each segment of a spline, too - those will also be stitched...) and this will make a lot more use of the faster graphics cards. And the biggest speedup can be expected on the higher end hardware, as that's where there is the most to gain.
Now, before everyone jumps up and down saying this is wonderful - there are two caveats here. Firstly, some things can't be done this way. Anything with animation won't get done this way. Neither will things that are alphablended (though alphamasked things are fine). So all them trees on the DLS won't work with it - creators will need to make them alphamasked rather than alphablended for this to work. Secondly, 50 slightly different houses in the estate won't work, as they are different. This technique will only benefit you when you re-use the same asset over and over. Of course, you'll want some variation - but maybe 15-20 each of 3 different types is an acceptable compromise. That's up to layout creators to decide"
Cheerio John
