Jump to content
Rolling Thunder Forums

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. ;)

Link to comment
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.

Link to comment
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 ....

Link to comment
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.

Link to comment
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.

Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...