Thread: Re: [Gpsbabel-misc] Clarification of the duplicate filter
Brought to you by:
robertl
From: Alex M. <al...@co...> - 2004-08-26 02:06:26
|
> This happens because we call xcsv_parse_style_buff at vecs.c as a > response to the "-i". Unfortunately, we call xcsv_destroy_style as > part of de-initting the read as a result of the "-f". We don't get > another chance to recreate it for the next -f. > > I'm not sure that removing the call to xcsv_destroy_style from > xcsv_rd_deinit and xcsv_wr_deinit wouldn't be a bad thing. Alex? > > This would only be a bad thing for the memory leak tester. :) For all intents and purposes, we *could* forgo the cleanup process until we either need to swap xcsv formats or the end of main(). There is something squirrely about that process that escapes me at the moment, but I don't think it's insurmountable. I'll take a look at it tomorrow and see what's up in there. Worst case, I think we'd we'd just reallocate the styles at _init time and drop a final call to xcsv_destroy_style() onto the end of main(). Not elegant, but I knew that it probably wouldn't be from day one. :) alex |
From: Robert L. <rob...@us...> - 2004-08-26 03:57:14
|
> >I'm not sure that removing the call to xcsv_destroy_style from > >xcsv_rd_deinit and xcsv_wr_deinit wouldn't be a bad thing. Alex? > > > This would only be a bad thing for the memory leak tester. :) If our leak tester is stopping us from doing The Right Thing, we've lost focus. (And don't get me wrong, it's entirely possible that I shone a leak tester colored light into your face after 54 hours of sleep deprivation and made you deal with this - in that case, the lost clarity is mine, not yours.) > we *could* forgo the cleanup process until we either need to swap xcsv > formats or the end of main(). There is something squirrely about I'm more worried about taking on 2 million waypoints (yes, folks actually do that) that on 2 million style sheets. We could make an insane amount of work for ourselves dicatating that everything is released, or we could Do The Right Thing. It sounds like we're agreeing that deferring (potentially until eternity) the call to xcsv_destroy_style from *_deinit isn't the worst fate ever. What if the blah_deinit brothers got a flag that declared them finalizers or not? > I think we'd we'd just reallocate the styles at _init time and drop a > final call to xcsv_destroy_style() onto the end of main(). Interesting. But is there really even any reason to realloc/reparse them? It's not like that set can change, right? > Not elegant, but I knew that it probably wouldn't be from day one. :) There are places where elgance earns bonus points. I'm not sure this is one of them. RJL |
From: Alex M. <al...@co...> - 2004-08-26 13:45:34
|
>If our leak tester is stopping us from doing The Right Thing, we've >lost focus. (And don't get me wrong, it's entirely possible that I >shone a leak tester colored light into your face after 54 hours of sleep >deprivation and made you deal with this - in that case, the lost clarity >is mine, not yours.) I think it just evolved that way. :) >I'm more worried about taking on 2 million waypoints (yes, folks >actually do that) that on 2 million style sheets. We could make >an insane amount of work for ourselves dicatating that everything >is released, or we could Do The Right Thing. It sounds like we're >agreeing that deferring (potentially until eternity) the call to >xcsv_destroy_style from *_deinit isn't the worst fate ever. > >What if the blah_deinit brothers got a flag that declared them finalizers >or not? We'd still need to deal with swapping between "-i s_and_t ... -i arc ... -i csv... -o ozi..." The mid-stroke changes in the parsing instructions are what kill us here. But... > > I think we'd we'd just reallocate the styles at _init time and drop a > > final call to xcsv_destroy_style() onto the end of main(). > >Interesting. But is there really even any reason to realloc/reparse >them? It's not like that set can change, right? Using the single "static" structure to maintain the set of parsing instructions almost dictates that we'd have to... If we're interested in being memory-friendly. I think it's trying to maintain the "state" of what's currently loaded that makes this a problem, I think (I'm still looking into this). Of course, simply removing the calls to xcsv_destroy_style() is a viable interim solution. But in the case of the 2 million style sheets, we'd alloc up a whole lot of memory really quick. I wonder if the proper solution is to simply maintain an array of xcsv_file structs. We load 'em up when we need to and keep 'em resident. That would add to the overall runtime size by a little, but would decrease the overhead of all the allocing and file reads going on when trying to handle each xcsv i/o operation as a single pass. Worst case, we'd only "waste space" once per format. I'll poke at it a bit today and see what shakes out. alex |