> S> Это какие? Сложно уследить за порядком сохранения-чтения? Ну да, ну да...

std::list<my_class *> mc;
...
foreach(my_class *c, mc)
{
 c->save();
}

Лучше будет и туда и туда выделить не по паре дней а по неделе

S> > S> Это какие? Сложно уследить за порядком сохранения-чтения? Ну да, ну да...

S> std::list<my_class *> mc;
S> ...
S> foreach(my_class *c, mc)
S> {
S>  c->save();
S> }
S>

class my_class {
public:
   int a;
   char *b;
   std::list<basic-String<whcar_t*> > li;
}

class A {
public:
   std::list<my_class *> mc 
}


main(){
   A *a = new A();
   a -> save();
}

13 13 13 13

S> Нет, Мамут, это не так

So why is the thing slower if it’s so much better?

Well let me elaborate a little more, but before I answer that directly, first let me tell you what things are almost certainly not the problem.

Not the problem #1: WPF

With the exception of some cases where we found that remoting WPF primitives over terminal server connections was slow, generally the WPF system is more than capable of keeping up with the editor. If you are seeing sluggish typing WPF is almost certainly not to blame.

Not the problem #2: Editor Primitive Operations.

The basic insert primitives are blazing fast, as low as a few microseconds even in very large files. If you’re seeing a problem, the chances that the text buffer is letting you down are slim to none.

Ok, so, if it’s not those things, what is it? There’s two good bets.

Compatibility Shims

The new editor is managed, and it has its own brand new managed interface. You can call it directly. However, there is lots of existing code that knows how to talk to the OLD editor and the old editor had a COM interface with its own particular API. We didn’t want to port all of the editor related code to the new editor’s managed interfaces – for several reasons but perhaps the most important is that there’s just so much of it. So we created a compatibility layer – shims – that allow old callers to use the new editor. That’s also important for our partners out there. That’s all fine and well but of course that means you’re going to be forced to use COM-interop where there was none before and of course those shims have to emulate the old editors behavior even when that wasn’t exactly the fastest choice in the west.

Event Listeners

Another reason why the editor can get bogged down is that various clients can register for notifications of interesting events. This is actually very popular (understatement) and important things like the language’s intellisense services want to be notified of various things going on in the buffer. Now it turns out that the actual editing primitives are so fast that the bulk of the cost of doing edits is actually in these various event processors. Sometimes because they are using shims, sometimes just because they are being over-aggressive in subscribing to things. Sometimes because they have their own personal problems that are only incidentally related to editing.

One way that you can see the difference in the root cause of editing yourself is to try your editing operations in a file named ‘foo.txt’ rather than ‘foo.cs’ or ‘foo.vb’ or whatever the case may be. This will disable many of the event listeners and give you a truer feel for what the editor itself is doing. Even that isn’t perfect because of course there are still listeners for bookmarks, and other kinds of things that are applicable to even plain text files.

It started development as an undergraduate college senior design project mentored by Microsoft, and is currently being maintained by some of the alumni that originally worked on it. Originally intended as a free replacement for the Microsoft Paint software that comes with Windows, it has grown into a powerful yet simple image and photo editor tool.