15 messages in com.googlegroups.sketchuprubyRe: None a need for speed| From | Sent On | Attachments |
|---|---|---|
| ultraviolet | 19 May 2007 09:36 | |
| TB | 19 May 2007 11:45 | |
| ultraviolet | 19 May 2007 13:07 | |
| Rich Morin | 19 May 2007 13:44 | |
| ultraviolet | 19 May 2007 14:46 | |
| Rich Morin | 19 May 2007 15:07 | |
| ultraviolet | 19 May 2007 15:40 | |
| ultraviolet | 21 May 2007 09:01 | |
| Rich Morin | 21 May 2007 10:05 | |
| ultraviolet | 21 May 2007 11:03 | |
| Mitchel | 21 May 2007 19:04 | |
| TB | 21 May 2007 19:47 | |
| TB | 21 May 2007 19:55 | |
| Jim | 21 May 2007 22:35 | |
| Jim | 21 May 2007 23:00 |
| Subject: | Re: None a need for speed |
|---|---|
| From: | ultraviolet (viol...@gmail.com) |
| Date: | 05/19/2007 02:46:17 PM |
| List: | com.googlegroups.sketchupruby |
hmmm, thx Rich. some definitely interesting ideas there. (but please, not GAs!! -if you only knew how many girlfriends have vanished/how much of my life i've already spent whilst mucking about with those things -lol)
re your first suggestion, surely if ever i can, i will only be importing model data deltas, but right now i'm in a situation where i want to import *brand new* 3rd party data into SU. however, if i understand you correctly it still might be worth trying to do the import in chunks; saving each chunk off as a temporary skp and then stitching the whole lot back together when i'm done. -especially as i strongly suspect that i'm running into trouble with the ruby gc that somehow gets avoided when SU loads a skp.
one question tho' -what do you mean by SU batch mode? i think i can probably save each chunk as a component and then use DefinitionList::load to do the stitching -is that what you mean?
definitely agree with you about the black-box stuff. -don't like to complain tooo much tho' as SU is pretty damn good in many other respects!
On 19 May, 21:45, Rich Morin <r....@cfcl.com> wrote:
Here are some partly-baked comments and suggestions:
Workarounds:
* Break the data into smaller pieces.
* Use SU in batch mode to process _changed_ pieces into skp format. If the data format contains "noise" values (e.g., time stamps), write a comparison script that ignores them. Otherwise, cmp(1) can tell you if the file's contents have changed.
* Look into creating "patch" files that only contain modified parts of the model. Load SU with a "base" data set, feed in any patches, then dump the model.
* If the model gets large enough that the skp loads become an issue, look into loading portions of the model "on demand". These could be partitioned by subsystem, level of detail, etc.
Analysis and Tuning:
* Monitor the amount of time that the batch processing takes for each piece of the model. As appropriate, sub-divide the model further.
If you find a particular piece of the model that seems to be a principal culprit, inspect that piece to see what uncommon characteristics it has. You may then be able to make optimizations to your code or model.
* If no obvious culprit(s) emerge, you may have to bring out the Big Guns. I've been thinking, for example, about ways to use Genetic Algorithms for this.
A genetic algorithm (or GA) is a search technique used in computing to find true or approximate solutions to optimization and search problems. ...
http://en.wikipedia.org/wiki/Genetic_algorithm
The basic idea, in this case, is that you would make a number of batch mode runs, determining which ones are taking the most time to load the data. Then, you "breed" and "mutate" their characteristics, creating another generation of run parameters. Rinse, repeat. After a few generations (and some tweaking), the "hot spots" should be quite evident.
Of course, if SU provided ways to receive feedback on which plugins and/or parts of a model cause it grief, much less of this "black box" analysis would be needed...
-r
--http://www.cfcl.com/rdm Rich Morinhttp://www.cfcl.com/rdm/resume
r...@cfcl.comhttp://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development