Jump to content
Rolling Thunder Forums
Sign in to follow this  
Hamish

Question as input for new Victory! tool.

  

19 members have voted

You do not have permission to vote in this poll, or see the poll results. Please sign in or register to vote in this poll.

Recommended Posts

In any case, the speed is, of course, directly proportional to the amount of information you extract from the file. Right now, I'm grabbing everything but the battle reports.

 

Loading time for for all of the vic data files (all the tech files and the province borders) is around half of a second. Loading a result file + turn file is near instant.

 

The 60 seconds/2 seconds comparison was made on my old Athlon system. Current times come from my core 2 due. Don't have times for excel anymore. Don't even have that installed currently. ;)

Share this post


Link to post
Share on other sites

Right now, I'm always running the program while debugging, and that's always a little slower than the final compiled product, but not by much. So far, I have not been annoyed by it's performance. I do not have any precise measurements whatsoever.

I changed the order entry part from the previous version of VOEP to make it faster and more stable, but it still seems the slowest part of the program. I guess it's because the changing controls just take the most time.

Share this post


Link to post
Share on other sites

That's odd. Changing controls shouldn't really cause even a noticable delay.

 

I have at least a dozen list views, literally dozens of edit boxes and a whole lot of check boxes, buttons and what not. All of those are constantly updated after each data entry, and that's after a full recalculation of the state of the nation. All of which happens near instant ....

Share this post


Link to post
Share on other sites

It may just be the fact that I'm really just an advanced amateur, I may be making some mistake that harms the performance.

In this new version I tried to implement some architectural principles, like an MVC approach. When you select an order from the pull down list, a reference to all ComboBoxes and Labels is passed to a controller object, which manipulates them as you enter additional fields. I still think it's the best approach and I don't know why it's not performing as well as I'd like to.

Share this post


Link to post
Share on other sites

That ought to work.

 

The software our company makes (which is an ERP package) is entirely based on this principle, where the entire data environment hooks in to the entire front end using the producer - consumer/viewer principle. A change in even one value on one record in one table triggers hundreds of cascaded updates, in dozens of forms concurrently.

 

This includes refreshes in virtual list views (which includes on-the-fly recalculation of scroller sizes), refreshes in drop down lists in combo boxes, automated lookups in thesauri, on-the-fly recalculation of calculated fields and what not. There are even parts of the front end that trigger all of this updating on each key stroke the user makes. And all of this is near instant, hardly any delays noticable.

 

But then again, our software is build on top of the Delphi VCL, and thus fully and natively compiled to pentium machine code.

Share this post


Link to post
Share on other sites

So have you guys been at it together by now? With JP having a complete input program already running (but not OK on win7) and Hamish working on a version that would run well on Win7, I'm wondering what the results look like. :-)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×