DotNetProjectResolver serialization

Hi Ilya,

Sorry, but no we haven't added that feature yet.

Hi!

Can you say when this feature will be added? Or tell us how can we get round your limitations..

To cash all source codes on each start of our system is a problem for us (we have about a hundred sources files)..

Sorry but we don't have a specific date on when this might be added. There are other higher priority items that we are currently working on.

If this is something that you absolutely require soon then you have an option of hiring our consulting services to implement it. There is more information on consulting on this page:
http://www.actiprosoftware.com/Purchase/ConsultingServices.aspx

>If this is something that you absolutely require soon then you have an option…

Sorry, but this feature was discussed TEN MONTHS AGO.

You propose a source code control that potentially has bad scalability within a huge amount of source files. There are two ways to get round it: either store a source code cash on the dist, or perform cashing in non-gui thread (as Visual Studio do).

As I understand you control cannot store cash and cannot perform cash in non-gui thread… Not good…

Ilya,

Please understand that we are a small company with limited resources and time. We do our best to meet the requests of our customers however we get feature requests daily from the thousands of customers we have. We have to prioritize them based on various criteria, with bug fixes being the highest priority. While we would love to implement every request that comes our way, we simply don't have the manpower to do so.

Back to the issue though. Loading of source is done mostly in a worker thread with a callback to the main thread to store the results. The actual parsing is done by the semantic parser service which runs in a worker thread if it is enabled. Do you have that enabled? If not, it will run in the main UI thread, which is bad. Once it finishes a document, it calls back to the main thread to merge the data into the SourceProjectContent but that should go very fast.

If you are sure it is still slow, then perhaps you could put together a small project that shows the slowness of the startup. This way we can debug to see if there are any immediate suggestions we can offer. And if not, perhaps we can continue discussion on how to implement cached source content. There are some issues to consider related to that which would need to be discussed.

Hi there,

I apologize for my previous post if it was too tactless. The problem was that I didn't know your control can parse source codes in a non-gui thread.

Now I see that the major bottleneck is in the way how we use parsing requests. I revised our code and saw that parsng requests was in the form: In the MainForm's constructor and Dispose() method, we already use Start() and Stop() calls for SemanticParserService.

I just removed CSharpSyntaxLanguage's constructor calls from the "foreach" cicle and created one instance of the language's object in the way: Does this way guarantee that my source files are processed in a worker thread?

One other thing is that back after you started the service in your MainForm constructor, you should also make sure you set a cache path on the project resolver. If you have done so, then yes, your code should be using the worker thread properly.

Thanks.