Альтернатива STL
Вот то, что я придумал после примерно часа возни ( GitHub Repo ): 
Я используя шаблон MVVM, чтобы сделать интерфейс максимально простым. Прямо сейчас, это просто заполняется некоторыми случайными данными.
XAML:
Модели представления:
class MainWindowVm : ViewModel
{
public MainWindowVm()
{
var rnd = new Random();
Prices = new ObservableCollection();
for (int i = 0; i < 8; i++)
{
var entry = new PriceEntryVm();
Prices.Add(entry);
entry.BuyOrders.CollectionChanged += OnOrderChanged;
entry.SellOrders.CollectionChanged += OnOrderChanged;
entry.Price = (decimal)110.91 + (decimal)i / 100;
var numBuy = rnd.Next(5);
for (int orderIndex = 0; orderIndex < numBuy; orderIndex++)
{
var order = new OrderVm();
order.Qty = rnd.Next(70) + 5;
entry.BuyOrders.Add(order);
}
var numSell = rnd.Next(5);
for (int orderIOndex = 0; orderIOndex < numSell; orderIOndex++)
{
var order = new OrderVm();
order.Qty = rnd.Next(70) + 5;
entry.SellOrders.Add(order);
}
}
}
private void OnOrderChanged(object sender, NotifyCollectionChangedEventArgs e)
{
if (e.Action == NotifyCollectionChangedAction.Add)
{
foreach (var item in e.NewItems)
{
var order = item as OrderVm;
if (order.Qty > LargestOrder)
{
LargestOrder = order.Qty;
}
}
}
}
private int _largestOrder;
public int LargestOrder
{
get { return _largestOrder; }
private set { SetValue(ref _largestOrder, value); }
}
public ObservableCollection Prices { get; }
}
public class PriceEntryVm: ViewModel
{
public PriceEntryVm()
{
BuyOrders = new OrderList(this);
SellOrders = new OrderList(this);
}
private Decimal _price;
public Decimal Price
{
get {return _price;}
set {SetValue(ref _price, value);}
}
public OrderList BuyOrders { get; }
public OrderList SellOrders { get; }
}
public class OrderList : ObservableCollection
{
public OrderList(PriceEntryVm priceEntry)
{
PriceEntry = priceEntry;
}
public PriceEntryVm PriceEntry { get; }
}
public class OrderVm : ViewModel
{
private int _qty;
public int Qty
{
get { return _qty; }
set { SetValue(ref _qty, value); }
}
}
Мне пришлось сделать некоторые предположения о наименовании вещей, но, надеюсь, вы должны получить базовое представление о том, что продолжается.
Он структурирован как список PriceEntry, каждый из которых содержит свойства Price, а также свойства BuyOrders и SellOrders.
BuyOrders и SellOrders - это просто списки заказов, которые имеют свойство Quantity.
XAML связывает список ценовых записей с шаблоном, который содержит сетку из 3 столбцов. Первый и третий столбцы этой сетки привязаны к другому набору элементов управления для каждого списка заказов. Шаблон для каждого заказа - это просто граница с Width, привязанным к Quantity заказа.
Все привязки означают, что простое обновление свойства или добавление ордера в список покупки или продажи записи цены будет автоматически распространяться на пользовательский интерфейс. Добавление или удаление PriceEntry также автоматически настроит пользовательский интерфейс.
Я еще не реализовал ваше автоматическое масштабирование, но основная идея заключается в том, чтобы использовать ValueConverter для привязки Quantity, чтобы она автоматически настраивалась на самый большой порядок.
В качестве дополнительного примечания, он использует этот пакет nuget для предоставления некоторого кода стандартного кода MVVM, но вы должны иметь возможность использовать все, что захотите, до тех пор, пока он вам дает INotifyPropertyChanged поддержка.
Здесь приведен дополнительный снимок экрана, показывающий динамический характер MVVM, обновляющего пользовательский интерфейс на основе таймера.
Для этого понадобилось всего несколько строк кода, чтобы случайным образом выбрать строку, затем случайным образом выбрать порядок в строке, затем добавить или вычесть небольшой случайное количество из количества.
_updateTimer = new DispatcherTimer();
_updateTimer.Tick += OnUpdate;
_updateTimer.Interval = TimeSpan.FromSeconds(0.01);
_updateTimer.Start();
private void OnUpdate(object sender, EventArgs e)
{
var entryIndex = _rnd.Next(Prices.Count);
var entry = Prices[entryIndex];
OrderList list;
list = _rnd.Next(2) == 1 ?
entry.BuyOrders :
entry.SellOrders;
if (list.Any())
{
var order = list[_rnd.Next(list.Count)];
order.Qty += _rnd.Next(0, 8) - 4;
}
}
14 ответов
Контейнеры STL не должны работать "действительно медленно" в отладке или больше никуда. Возможно, Вы неправильно используете их. Вы не работаете против чего-то как ElectricFence, или Valgrind в отладке - Вы? Они замедляют что-либо вниз, которое делает много выделений.
Все контейнеры могут использовать пользовательские средства выделения, которые некоторые люди используют для улучшения производительности - но я никогда не должен был использовать их сам.
Qt повторно реализовал большую часть материала библиотеки стандарта C++ с различными интерфейсами. Это выглядит довольно хорошим, но это может быть дорого для коммерчески лицензионной версии.
Редактирование: QT был с тех пор выпущен под LGPL, который обычно позволяет использовать его в коммерческом продукте без bying коммерческая версия (который также все еще существует).
Проверка структур данных и алгоритмов с объектно-ориентированными шаблонами проектирования в C ++. Бруно Прейсс http://www.brpreiss.com/
Что относительно библиотека ACE ? Это - объектно-ориентированная платформа с открытым исходным кодом для параллельного обеспечения связи, но это также имеет некоторые контейнерные классы.
Ultimate ++ имеет собственный набор контейнеров - не уверен, что вы можете использовать их отдельно от остальной части библиотеки: http://www.ultimatepp.org/
MSVC использует очень тяжелую реализацию проверенных итераторов в сборках отладки, которые уже обсудили другие, таким образом, я не повторю его (но запущусь там)
Еще одна вещь, которая могла бы представлять интерес для Вас, то, что Ваша "отладочная сборка" и "сборка конечных версий", вероятно, включают изменяющий (по крайней мере) 4 настроек, которые только свободно связаны.
- Генерация .pdb файла (статья/Zi и ссылка / ОТЛАДКА), который позволяет символьную отладку. Можно хотеть добавить/OPT:ref к опциям компоновщика; компоновщик отбрасывает не имеющие ссылки функции, если не делающие .pdb файл, но с РЕЖИМОМ ОТЛАДКИ / это сохраняет их всех (начиная с отладочных символов, ссылаются на них), если Вы не добавляете этот expicitly.
- Используя отладочную версию библиотеки времени выполнения C (вероятно, MSVCR*D.dll, но это зависит, на каком времени выполнения Вы используете). Это сводится к / MT или/MTd (или что-то еще, не используя dll время выполнения)
- Выключение оптимизации компилятора (/Передозировка)
- установка препроцессора #defines ОТЛАДКА или NDEBUG
, Они могут быть переключены независимо. Себестоимости ничто в производительности во время выполнения, хотя это добавляет размер. Второе делает много функций более дорогими, но оказывает огромное влияние на malloc и свободный; версии среды выполнения отладки стараются "отравить" память, которой они касаются со значениями, чтобы ясно дать понять неинициализированные ошибки при работе с данными. Я верю с MSVCP* реализации STL, он также устраняет все выделение, объединяющее, который обычно делается, так, чтобы утечки показали точно блок, Вы думали бы и не некоторый больший блок памяти, которую он подвыделял; это означает, что выполняет больше вызовов к malloc сверху их являющийся намного медленнее. Третье; хорошо, тот делает много вещей (, этот вопрос имеет некоторое хорошее обсуждение предмета). К сожалению, необходимо, если Вы хотите, чтобы единственное продвижение работало гладко. Четвертое влияние много библиотек различными способами, но самый известный это компилирует в или устраняет, утверждают () и друзья.
, Таким образом, Вы могли бы рассмотреть создание сборки с некоторой меньшей комбинацией этих выборов. Я делаю большое использование сборок, что использование имеет символы (/Zi, и свяжите ОТЛАДКУ/), и утверждает (/DDEBUG), но все еще оптимизированы (/O1 или/O2 или безотносительно флагов, которые Вы используете), но с указателями стекового фрейма, сохраненными для ясных следов (/Oy-) и пользования нормальной библиотекой времени выполнения (/MT). Это работает близко к моей сборке конечных версий и является semi-debuggable (следы прекрасны, единственно ступающий является немного дурацким на исходном уровне; уровень ассемблера хорошо работает, конечно). У Вас может быть однако много конфигураций, которые Вы хотите; просто клонируйте свой выпуск один и включите любые части отладки, кажутся полезными.
Извините, я не могу оставить комментарий, поэтому вот ответ: EASTL теперь доступен на github: https://github.com/paulhodge/EASTL
Если Вы используете Visual C++, то необходимо взглянуть на это:
http://channel9.msdn.com/shows/Going+Deep/STL-Iterator-Debugging-and-Secure-SCL/
и ссылки от той страницы, которые покрывают различные расходы и опции всего режима отладки, проверяющего, который делает STL MS/Dinkware.
, Если бы Вы собираетесь задать такой вопрос зависимого платформы, это была бы хорошая идея упомянуть Вашу платформу, также...
Я буду держать пари, что Ваш STL использует проверенную реализацию для отладки. Это - вероятно, хорошая вещь, поскольку она поймает переполнения итератора и такой. Если это - так большая часть проблемы для Вас, может быть переключатель компилятора для выключения его. Проверьте свои документы.
Для больших приложений, критичных к производительности, создание собственных контейнеров, специально адаптированных к вашим потребностям, может стоить затрат времени.
Я говорю о настоящей разработке игр здесь.
Если Ваши под управлением Visual Studio можно хотеть рассмотреть следующее:
#define _SECURE_SCL 0
#define _HAS_ITERATOR_DEBUGGING 0
Это только для итераторов, какие операции STL Вы формуете? Можно хотеть посмотреть на оптимизацию операций памяти; т.е., использование изменяет размеры () для вставки нескольких элементов сразу вместо того, чтобы использовать поп/нажатие для вставки элементов по одному.
Мой опыт состоит в том, который хорошо медленно разрабатывал выполнения кода STL в сборках отладки, потому что оптимизатор выключен. Контейнеры STL испускают много вызовов конструкторам и оператору =, который (если они - легкий вес) встраивается/удаляется в сборках конечных версий.
кроме того, Visual C++ 2005 и имеет проверку, включенную для STL и в сборках выпуска и в отладки. Это - огромный пожиратель ресурсов производительности для тяжелого STL программного обеспечения. Это может быть отключено путем определения _SECURE_SCL=0 для всех единиц компиляции. Обратите внимание на то, что наличие различного _SECURE_SCL состояния в различных единицах компиляции почти наверняка приведет к бедствию.
Вы могли создать третью конфигурацию сборки с проверкой выключенного и использование что отладить с производительностью. Я рекомендую Вам сохранить настройку отладочного процесса с начинанием работу, хотя, так как очень полезно поймать ошибочные индексы массива и материал как этот.
EASTL является возможностью, но все еще не прекрасный. Paul Pedriana из Electronic Arts сделал расследование различных реализаций STL относительно производительности в игровых приложениях, сводка которых найдена здесь: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
Некоторые из этих корректировок рассматриваются для включения в стандарт C++.
И примечание, даже EASTL не оптимизирует для неоптимизированного случая. У меня был файл Excel w/некоторая синхронизация некоторое время назад, но я думаю, что потерял ее, но для доступа это было что-то как:
debug release
STL 100 10
EASTL 10 3
array[i] 3 1
наибольший успех, который я имел, прокручивал мои собственные контейнеры. Можно свалить тех к близкому массиву [x] производительность.