RE: [OpenMap Users] CADRG load time issue

Don,

>>> I think there is a major problem in that the RpfTocHandler checks to
see of the frames actually exist while it is loading the layer for the
first time.<<<

I did some optimizing of OpenMap on my own, and checking for the existence
of the frames is a major bottle neck.

>>>(It wasn't
written with checking for Gb of data over the network in mind).<<<

In my small test, I load 6 GIG of data off a shared network drive. By
taking out the existence check of files listed in the A.TOC, I saw a very
large performance boost. For reference, I have a disk drive sent to me from
a production system that has 190 GIG of map data on it. (Although I don't
see any properties files that actually loads all 190 GIG at once). Any way
you can optimize the RpfTocHandler code would be sweet. I made a tiny
change to BinaryFile and BinaryBufferedFile also that gave me boosts doing
network loads.

>>> I'm not sure why you see a performance
difference in the RpfLayer between 4.5.3 and later versions, the code
that does this work hasn't changed for much longer than that<<<

It's not that the code is taking any longer. It's that while OpenMap is
loading the CADRG data, it locks up my application. In version 4.5.3, while
OpenMap was loading, my application still functioned. While loading, the
little boxes on the lower right hand corner of my map display turned red. I
knew the data was loaded once all the little boxes were green. Now, in 4.6,
my entire application freezes, and the user can perform no other functions
while OpenMap is loading. I haven't gotten a chance to dig into v4.6 much
at all yet, but I'm guessing from the behavior, the i/o work is no longer
being done in a background thread. I say this because while the i/o work is
being done, my machine doesn't lock up, only my application.

I'd be glad to help any way I can, just let me know.
Leah

-----Original Message-----
From: owner-openmap-users@bbn.com [mailto:owner-openmap-users@bbn.com] On
Behalf Of Don Dietrick
Sent: Tuesday, June 15, 2004 11:42 AM
To: Lonnie Goad
Cc: openmap-users@bbn.com
Subject: Re: [OpenMap Users] CADRG load time issue

Lonnie,

I think there is a major problem in that the RpfTocHandler checks to
see of the frames actually exist while it is loading the layer for the
first time. While this is taking place in a separate thread, I think
the I/O burden it places on the system is causing all resources to be
diverted to that process, and it the machine kind of hangs. I've seen
this effect in the DTEDCoverageLayer when it is building the coverage
file and checking what frame files it has (it's even more dumb, and
more intensive, actually). I'm not sure why you see a performance
difference in the RpfLayer between 4.5.3 and later versions, the code
that does this work hasn't changed for much longer than that (It wasn't
written with checking for Gb of data over the network in mind).

I've made modifications to the RpfTocHandler and other classes in the
package so they don't do that check. I also want to reorganize how the
coverage boxes are organized in the RpfTocHandler, so they are grouped
by scale, limiting the search algorithm for pertinent coverage to
scales that make sense for the given projection scale.

The first set of changes will be in the maintenance release this month.
  The second set of changes may be.

- Don

On Jun 14, 2004, at 1:29 PM, Lonnie Goad wrote:

> I noticed that I and another person had posted on this issue before
> and I was wondering if anybody else had the same issue and if they had
> come to a resolution.  The issue is that when initially loading data
> for an RpfLayer the time for this has increased significantly since
> OpenMap 4.5.3.  The load time isn’t even the real issue; the real
> issue is that loading CADRG data freezes the application until it is
> done.  I have gone so far as to make sure that the thread for loading
> the data is working properly and it appears to be doing so, but
> something is still causing the application to hang up.  This occurs if
> the CADRG layer is turned on at startup or if turned on during run
> time.  I am using a lot of data and it is taking approximately 2.5
> minutes to load.  I have tried making a new TOC file with MakeToc and
> have cut the time down to just over 2 minutes.  Combining Toc files is
> not a realistic solution in the first place because my application
> doesn’t provide map data and my users are not going to know how to
> handle doing that.  I guess I am just hoping that somebody out there
> has found the bottleneck and is willing to share the info.
>
>  
>
> Thanks,
>
>  
>
> ************************
>
> Lonnie Goad - Programmer
>
> OptiMetrics Inc.
>
> 2107 Laurel Bush Rd. Suite 209
>
> Bel Air, Md. 21015
>
> LGoad@OptiMetrics.org
>
> http://www.OptiMetrics.org
>
> (410)569-6081 ext: 105
>
> fax: (410)569-6083
>
>  
>

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Dietrick, dietrick@bbn.com
BBN Technologies, Cambridge, MA
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe
openmap-users"]
--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]