This project is read-only.

Opening Project file is slower.

Dec 12, 2011 at 12:04 PM

Hi


When opening a "dspx" project file, the map navigation is remarkably slower than starting from "scratch" and adding the same layer to the map.

Why is this? A Bug?


Thank you

Dec 12, 2011 at 4:57 PM

I'm having the same problem.

I think this is because of the way how the methods in DotSpatial.Serialization were programmed. It uses reflection to assign the correct Types to the dspx xml elements. I think that using reflection is one reason why it is so slow.

I'm also having a second problem - Opening the dspx file doesn't report any progress and it blocks the UI (the application is 'frozen') when a project file is being opened. I would like to be able to open the dspx file using BackgroundWorker so that I don't block the UI.

Dec 12, 2011 at 5:02 PM
See if sealing the last class improves the speed of reflection.
It can still be 'extended' using extension methods.


On Mon, Dec 12, 2011 at 8:57 AM, [email removed] wrote:
> From: jirikadlec2
>
> I'm having the same problem.
>
> I think this is because of the way how the methods in
> DotSpatial.Serialization were programmed. It uses reflection to assign the
> correct Types to the dspx xml elements. I think that using reflection is one
> reason why it is so slow.
>
> I'm also having a second problem - Opening the dspx file doesn't report any
> progress and it blocks the UI (the application is 'frozen') when a project
> file is being opened. I would like to be able to open the dspx file using
> BackgroundWorker so that I don't block the UI.
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
Dec 12, 2011 at 5:04 PM
If not, then it may be that the serialization needs to move to using
the .net xml classes, and then you can pre-compile the serialization
methods with xsd.exe

On Mon, Dec 12, 2011 at 9:02 AM, david valentine
<david.valentine@gmail.com> wrote:
> See if sealing the last class improves the speed of reflection.
> It can still be 'extended' using extension methods.
>
>
> On Mon, Dec 12, 2011 at 8:57 AM, [email removed] wrote:
>> From: jirikadlec2
>>
>> I'm having the same problem.
>>
>> I think this is because of the way how the methods in
>> DotSpatial.Serialization were programmed. It uses reflection to assign the
>> correct Types to the dspx xml elements. I think that using reflection is one
>> reason why it is so slow.
>>
>> I'm also having a second problem - Opening the dspx file doesn't report any
>> progress and it blocks the UI (the application is 'frozen') when a project
>> file is being opened. I would like to be able to open the dspx file using
>> BackgroundWorker so that I don't block the UI.
>>
>> Read the full discussion online.
>>
>> To add a post to this discussion, reply to this email
>> ([email removed])
>>
>> To start a new discussion for this project, email
>> [email removed]
>>
>> You are receiving this email because you subscribed to this discussion on
>> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>>
>> Please note: Images and attachments will be removed from emails. Any posts
>> to this discussion will also be available online at codeplex.com
Dec 13, 2011 at 5:41 PM

I'm in favor of serialization using standard .Net classes. The current output XML format is far more verbose than needed. The standard .Net classes serialize to XML in a more concise, readable format. When I looked into this a year ago, replacing the serialization mechanism wasn't trivial due to the use of a rather complex hierarchy of classes and interfaces.

Of course, we'll want to continue to support reading the current file format if we make the switch.

Dec 13, 2011 at 5:59 PM
verbose... just compress it. that's what MS did for the new office formats.

Add xml serialization attributes to the same elements that are on the
dotspatial serialization, and see what happens.

On Tue, Dec 13, 2011 at 9:41 AM, [email removed] wrote:
> From: mudnug
>
> I'm in favor of serialization using standard .Net classes. The current
> output XML format is far more verbose than needed. The standard .Net classes
> serialize to XML in a more concise, readable format. When I looked into this
> a year ago, replacing the serialization mechanism wasn't trivial due to the
> use of a rather complex hierarchy of classes and interfaces.
>
> Of course, we'll want to continue to support reading the current file format
> if we make the switch.
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
Mar 29, 2012 at 8:03 AM

Hi guys, any success on fixing this?