Printable View
Actually, this is not true. You could create an add-in dll and tell VS to use it in the autoexp.dat file. You can then write the code in the dll to do a custom expansion.Quote:
Originally posted by KevinHall
In VS .NET 2003, there is a hook to build your own display string for a given type. Granted this is still not perfect as there is no way to do custom expansions, but it's still better than VS 6.0.
The only documentation I can find in MSDN concerning using the add-in dlls is a sample DLL project which formats times. I did not see any way to do expansions using that API. If there is a way, great! I would love to see someone (possibly even me) make a DLL that would perform some more meaningful expansions for the STL. Can you point me somewhere where there is more meaningful documentation on the feature? (Really, I did search MSDN and the web. I just could not find anything beside that one sample dll).
Well, maybe I didn't exactly ask...Quote:
Originally posted by Yves M
I guess nobody asked for it, but here is some code that shows timing differences between std::list with and without my custom allocator and std::vector. The custom allocator essentially reserves all memory up-front.
;)Quote:
Originally posted by Paul McKenzie
The STL containers aren't constrained into doing the default memory management. I don't see why a custom allocator couldn't be written for std::list if "reserved memory" were an issue.
Yves, thanks for the informative post. You should post it in the C++ FAQ.
Regards,
Paul McKenzie
I agree with Paul -- Yves, that was a great post. How to use non-standard allocators would be a good FAQ too.
- Kevin
Try putting this in the watch window:Quote:
Originally posted by voidspace
I can view the value of nRow
but I cannot directly view the values of it->nRow or it->nCol or any of its members at codepoint A. This is using VS.Net 2003. It is kinda important for me to know this as there are thousands of lines of STL code which other programmers had written and programmers are not perfect. They can leave bugs here and there and to be able to debug into STL data is a requirement from my prespective. With superfast machines (hardware wise) it is important to be able to debug and track or integrate new features into existing architecture quickly and easily rather than speed.
iter->second
or if you were using VS6 you would put:
iter._Ptr->_Value
or
iter._Ptr->_Value.second to see the actual value.
Yves,
I don't see the
in the MemoryPool class. Let me know if I'm wrong on something.Code:delete [] m_data;
Regards,
Paul McKenzie
Yves,
I did specifically ask for it and thank you!
There are a few things I noticed that will make this a problem in VC6 so, if its ok with you, I'll modify the code a little to make it compatible. Then slap Kevin's class in here to for the "user-defined" class, and then offer a few optimizations, if that’s ok.
Needs a few things, like _Charalloc, from my quick perusal.
And as Paul noticed, its missing the destructor for deleting m_data.
Nothing serious though.
A top rate response! I'll get back to you hopefully this afternoon.
Thanks again, much appreciated.
Sorry, you are of course right, the destructor of MemoryPool should free the memory. First I was using a std::vector, that's why I didn't think about it :/Quote:
Originally posted by Paul McKenzie
Yves,
I don't see the
in the MemoryPool class. Let me know if I'm wrong on something.Code:delete [] m_data;
Regards,
Paul McKenzie
I have corrected the original code.
Of course, VC6 doesn't handle templates correctly and hence the whole rebind mechanism cannot work in the standard way. If you want to implement a rebind for VC6, you will have to write code that is implementation-specific for the STL you are using. If you use STLPort, then the way to do it is to inject your specialisations into the _STLP namespace. There is a thread somewhere on the Non-VC forum where that is detailed.Quote:
There are a few things I noticed that will make this a problem in VC6 so, if its ok with you, I'll modify the code a little to make it compatible.
Oh, by the way, I didn't give any credits, but as you can probably guess, the MyAlloc allocator is not actually mine (hence the non-sensical comments), but it's taken from Jossutis' book on STL.
What is _Charalloc ?Quote:
... like _Charalloc...
Hi Yves,
I think you might find this interesting, I did a quick drop in and run of the code, as expected, due to VC6 there were a few errors, so I commented out the custom allocated list for the moment and ran the test with the others just for fun and I found this to be interesting:
std::vector with reserve : 0.032881
std::vector without reserve : 0.030954
Standard allocator with std::list: 1.207932
C-style array : 0.014080
What I think is interesting is the vector with and without the reserve. I think this can be chalked up to the VC6 compiler pumping out some inefficient code. I'll run it with .NET later to compare. But also std:list is off from your result to mine, but .NET has exception handing in the STL code now, so that might account for it. I have a release .NET on ext HD that hopefully I'll get around to using to test this, but got a lot to do before Thanksgiving.
Which reminds me, if I don't get around to it today, I hope you all have a great Thanksgiving!
PS: _Charalloc is used by list for allocation. its a member of the allocater class, its in "XMemory":
it gets called in list in _BuyNode, in list:Code:char _FARQ *_Charalloc(size_type _N)
{return (_Allocate((difference_type)_N,
(char _FARQ *)0)); }
Its just one of the VC6 things I believe, nothing that can't be easily fixed.Code:_Nodeptr _Buynode(_Nodeptr _Narg = 0, _Nodeptr _Parg = 0)
{_Nodeptr _S = (_Nodeptr)allocator._Charalloc(
1 * sizeof (_Node));
_Acc::_Next(_S) = _Narg != 0 ? _Narg : _S;
_Acc::_Prev(_S) = _Parg != 0 ? _Parg : _S;
return (_S); }
This can't be right, unless the Dinkumware STL for VC6 is outright bad. Try moving the calls to the different functions around in main(). The problem I have with all these timing examples is that:Quote:
[i]Originally posted by oktronic
std::vector with reserve : 0.032881
std::vector without reserve : 0.030954
Standard allocator with std::list: 1.207932
C-style array : 0.014080
a) application startup time may have an influence (so the first function may have a longer time than expected)
b) memory fragmentation issues. Try putting any other function behind the std::list without custom allocators and you'll see its performance drop.
Oh, and by the way, there was another error in the code. The reserve should only reserve space for TEST_SIZE integers, the 1 million is a leftover from when I had that parameter fixed. So that may account for the discrepancy you get.
Yes that may be a slowdown factor. But then again vector.push_back could also throw an exception, no ?Quote:
But also std:list is off from your result to mine, but .NET has exception handing in the STL code now, so that might account for it.
Ok, that's what I was referring to when I said that custom allocators for VC6 have to be hard-coded with respect to your current STL. Very ugly :/Quote:
PS: _Charalloc is used by list for allocation. its a member of the allocater class, its in "XMemory":
Hi Yves,
Yeah, VC6 was horrible at doing templates, which is one of the reason alot of people avoided it. It has a very bad habit of getting all confused when you are using multiple templates, especially when they are in the same function as they are here. I'm pretty sure that if I move them around that I'll drop performance on one and gain on on another, as you suggested.
I made the change to vector and the BM for it is now 0.023746. bounced around a lot at this res, but it stayed -.01 from its non-reserved buddy. Sorry I didn't notice that, I didn't look too hard at the functions since its was a quick compile and run. I just dropped it into a project I'm working on just added a messagebox at the end to display the results. I'll need to remember to get it all out before my proj gets out the door, lol.
Anyways, thanks again. I'll get back to you with comparisons as soon as I get the chance.
The timing for std::list under both VC++ 6 (from oktronix)
and VC++ NET (from Yves) are very disrtubing. Here are
my results using VC++ version 5 (on a 450MHz laptop) :
Timing c-style array
Timing std::vector with reserve
Timing std::vector without using reserve
Timing std::deque
Timing Standard allocator with std::list
std::vector with reserve : 0.144907
std::vector without reserve : 0.334736
std::deque : 0.205166
Standard allocator with std::list: 1.01896
C-style array : 0.0716573
(I also added std::deque).
I also ran the code using g++ 3.2.2 under RedHat Linux.
I left the results at work, but they were similar to above.
std::list with the custom allocator code being about 3 times
faster than with the standard allocator. Under g++, I don't
have a high performance timer, so I just used clock() and
jumped the number of elements up to 1 million.
I'm baffled... I just tried the code (without the custom allocator) in VC6 and get these results:
Why is std::list so slow in VC.NET ? I have tried disabling exceptions, but that makes no difference at all. Is it implemented in a completely different way or something ?Code:// VC6 with STLPort
std::vector with reserve : 0.00840023
std::vector without reserve : 0.0217835
Standard allocator with std::list: 0.106455
C-style array : 0.00862987
// VC.NET 2003 with Dinkumware
std::vector with reserve : 0.00846281
std::vector without reserve : 0.0431672
Standard allocator with std::list: 21.2144
C-style array : 0.00862149
Hum, maybe a partial answer is the fact that inserting an element in VS.NET's STL updates an initial size count, while STLPort doesn't do that, but that doesn't quite account for a 200-fold increase...
Another answer may be that memory management was changed between the runtime for VC6 and the one for VC7, so that small objects occur a higher penalty. I'll try this and let you know.
Mystère et boule de gomme ;)
[edit:
I officially don't get it. The actual thing that is strange is that std::list is as fast as it is in VC6 in the first place. I tried the following code:
I set TEST_SIZE to 100 thousand and the multiplier to 10, so that the results are somewhat the same as previously. I had to run the tests for std::list and the fun_new_test separately, since either one of them fragments memory much too heavily, so results would be skewed in favour of the first one that gets called.Code:void fun_new_test()
{
int *a[TEST_SIZE];
for (int i = 0; i < TEST_SIZE; ++i) {
a[i] = new int;
}
for (i = 0; i < TEST_SIZE; --i) {
delete a[i];
}
}
Results:
Maybe the solution to this riddle would lie in the fact that STLPort already uses a better allocator than just plain new ? It would certainly explain these results, but I'm not quite sure what the explanation would be for VC6/5+Dinkumware to be faster than VC.NET+Dinkumware...Code:// VC6
Standard allocator with std::list: 0.127351
Standard allocator (new_test) : 13.2146
// VCNET
Standard allocator with std::list: 17.2856
Standard allocator (new_test) : 15.2608
Yves, try VC 7.0 using STLPort.
Regards,
Paul McKenzie
I'd love to, but that'll have to wait until I have a bit more time to set up STLPort under VC.NET. Actually, it's VC7.1 (VC.NET 2003), I don't know if that makes any difference.Quote:
Originally posted by Paul McKenzie
Yves, try VC 7.0 using STLPort.
Regards,
Paul McKenzie