Дискуссии о C#/.NET на русском - 2018-04-15

« first day (974 days earlier) ← previous day next day → last day (2057 days later) »

12:17 AM

@VladD финальынй вариант http://paste.org.ru/?if2hxx
Eric Lippert испортил мою веру в volatile (и вообще непонятно тогда зачем нужен он если он ничего не гарантирует)

5 hours later…

5:02 AM

@VladD Я не могу понять, мне нужно генерировать его во ViewModel'е чтоли? Тоесть я у своей реализации RelayCommand, делаю метод OnCanExecuteChanged, в нем я генерирую событие CanExecuteChanged, так? Вызывать метод OnCanExecuteChanged в нужных логических местах моего ViewModel'а, так чтоли?

Андрей NOP

@Bretbas да

Пример:

0

A: Изменение состояние кнопки

Я бы написал такую простую команду-переключатель (ее потом можно использовать в других местах при необходимости): public class ToggleCommnad : ICommand { protected readonly Action<object> _execute; public event EventHandler CanExecuteChanged; public ToggleCommnad(Action<object> exe...

5:24 AM

@АндрейNOP Я понял. Ок:)

@АндрейNOP, Слушай, а зачем нужен CommandManager.RequerySuggested?

Я просто видел, что реализовывают это событие к подписке на это событие

1 hour later…

Андрей NOP

6:27 AM

@Bretbas хз, никогда дела не имел с ним

@АндрейNOP ну вот такую я реализацию видел события:

		public event EventHandler CanExecuteChanged
		{
			add
			{
				if (canExecute != null)
					CommandManager.RequerySuggested += value;
			}
			remove
			{
				if (canExecute != null)
					CommandManager.RequerySuggested -= value;
			}
		}

Андрей NOP

6:41 AM

@Bretbas т.е. фактически подписчика подписываем на CommandManager.RequerySuggested?

@АндрейNOP Да, и я кстати проверил. После этого, не нужно явно генерировать событие CanExecuteChanged

WPF сама начинает это делать, правда я не понимаю когда.

Андрей NOP

7:34 AM

@Bretbas странно, как-то нехорошо это. Создаётся лишняя нагрузка на опрос бесконечный. Брейкпоинт не пробовали ставить и смотреть сколько раз вызывается?

7:49 AM

@АндрейNOP пробовал. Ну вызывается точно, когда окно получает фокус

@АндрейNOP А как сделать, чтобы контрол не получал фокус от Tab в WPF?

8:11 AM

@Bretbas чтобы использовать CommandManager для отслеживания CanExecute. Он своими методами при получении фокуса на элементах подергивает CanExecute у команд. Так себе решение.

8:31 AM

@vitidev Ну все зависит же от текущей ситуации. У меня например сейчас есть 3 DataGrid и еще некоторые контролы, мне нужно, чтобы всякий раз, когда изменялись какие-то данные во всех этих DataGrid и в некоторых контролах, срабатывало CanExecute с моей проверкой

@Bretbas ну либо вы сами следите за тем когда дергать CanExecuteChanged либо делегируете это CommandManager-у, который дергает периодически CanExecuteChanged когда он считает нужным (смена фокуса, пользовательский фокус или еще чего). и время от времени вы делаете CommandManager.InvalidateRequerySuggested

@vitidev а это что CommandManager.InvalidateRequerySuggested

@vitidev аа, ручной вызов

угу. что то происходило в фоновой работе, гуи не трогался и некоторые команды смогли стать CanExecute true. И вы дергаете "мол подергай ты CanExecuteChanged подписчиков"

@vitidev а как сделать, чтобы контролы от Tab не получали фокус в WPF? А то у меня у меня все стирилизировано, и черный пунктир вокруг контрола при фокусе, не очень красиво

@vitidev Ага:) Это понял. Ну вы предпочитаете сами вручную вызывать всегда CanExecuteChanged ?

то есть если у вас на форме забиндено 100500 команд, то регулярно эи 100500 команд будут дергаться CanExecute

@Bretbas в самомальном MVVMC да, а в готовых фреймворках менее удобно. Вообще оно все не силшком удобно.

стараюсь вот так
public RelayCommand DeleteAppCommand => CreateCommand(DeleteApp, () => SelectedApp != null, false)
.DependFrom(this, nameof(SelectedApp));

вот тут false говорит не добавлять в CommandManager и следить за изменениями SelectedApp явно. а значит эту команду и ее CanExecute лишний раз не дергают.

не то же самое что ReactiveUI, но хамл плохо подходит под Reactive и я, устав бороться, сделал вот так

8:43 AM

@vitidev ReactiveUI - это фреймворк какой-то чтоли?

угу. в реактивном стиле. где все - источник событий.

@vitidev В плане источник событий? Как это понять?

ну вот LINQ - она вытягивает данные сама обходит за ними
а реактиве подход обратный - данные "выталкиваются" когда они появляются и уведомляют всех подписчиков.

в обоих случаях делаются цепочки, где в рективе если где то появились данные то он вытолкнет их по всем подписантам

таким образом любое событие дернет всех кто за ним следит

вот CommandManager не знает когда CanExecuteChanged потому время от времне за этим бегает. это pull подход
а push подход где сам источник событий уведомит всех

в общем то можно и так подписываться на события изменения, но в реактиве во главе угла стоит понятие что все есть "серия событий"

то есть вы кликаете мышью - это серия кликов
а если меняется свойство - это серия изменения свойств

а если все есть "поток событий/данных" то можно просто подписаться на него и при появлении данных само все дернет.
и вот тут все непривычно но неплохо...но WPF на обратной модели же и поптка подружить 2 мира выглядит не очень удобной

8:59 AM

@vitidev так это не долго?

@Bretbas что?

@vitidev вызывать несколько событий, если вызывается одно?

ну в реактиве подходе уведомление о новых данных получают все кто подписался. А значит не как CommandManager с мыслью "а вдруг кто изменился опрошу ка я всех лишний раз на всякий случай", а просто подписка за изменениями.
Просто всё представляется как "поток данных push", вообще все. и вместо подписки на INPC у вьюмодели мы представляем свойство вм как ReactiveProp который по факту тот же поток данных с моделью push (сам всех уведомит)

@vitidev Понятно:) Ну тоже норм

@vitidev Блин, как мне этот чертов Tab отключить?:)

@Bretbas ну так то да. в андроид норм, а WPF то любит свой INPC и CommandManager и дружить одно с другим получается как то плохо. теряется декларативность

9:40 AM

@АндрейNOP Ну, ItemsSource="{Binding Answer.Variants}"?

@vitidev Ну хорошо, а чем вам мой метод не нравится?

@VladD тем что я его не понимаю как его использовать. я не понимаю что такое нематериализованные таски, когда в моей задаче все таски должны быть параллельны

@vitidev Вы хотите Task.WhenAll?

Но не хотите к списку тасков применять ToList?

Верно?

Или в чём проблема?

у меня создается миллион параллельных! тасков. Task.WhenAll требует их материализовать в ToList (а сам он еще в ToArray сделает) чтобы не грузить LOH

Ну хорошо, миллион.

И где они вас?

важно что они параллельные. мы сразу стартуем весь миллион и там уже шедулер пусть сам разбирается

9:44 AM

В каком-то контейнере?

tasks.Add(func(client)); //не ждем, идем к следующему клиенту

Вот вы завели их миллион

И что

@vitidev что такое tasks?

var tasks = new List<Task>();

ну отлично, а в чём проблема?

Task.WhenAll(tasks)

var tasks = new List<Task>(); попадет в LOH 3жды

9:45 AM

@vitidev Ну и хорошо, а в чём проблема?

у вас он и так есть

вы не можете не иметь списка всех тасков в каком-либо виде

я не хочу попадания в LOH. попадать туда будет все часто, а чиститься редко. Серверный GC вообще как еж птица гордая. Ну и OOM от 32битности мне в свое время крови попил

ну вот в своем решении я его и не имею

а ваше решение вообще не пойму как прикурчивать

У вас уже есть tasks

И он таки попадает в LOH

Это вы обойти не можете никак

или вы хотите избавится от списка tasks?

я ж не умею читать мысли. скажите, что у вас есть, и чего вы хотели бы добиться

@VladD он есть только в оригинальном варинте. в варианте TaskWhenAllTracker никаких List<Task>() не материализуется.

@vitidev Не понял

Что такое TaskWhenAllTracker?

видимо вы не сходиле по ссылке paste.org.ru/?srd5yd

9:50 AM

а, нет ещё

момент

ну, э

вы вместо прост одного массива тасков создаёте миллион Continuation'ов

вы уверены, что это оптимизация?

верно.

я что-то думаю, что это пессимизация

потому что связь между тасками явно намного дороже одного элемента массива

без понятия. ну я избегаю 2+ LOH структур List<Task> и Task[] внутри WhenAll

@vitidev Ну так измерьте!

не могу. под дотнекоре дотмемори не пашет

9:52 AM

Ну и что, что LOH? Вам профайлер показал, что с ним плохо?

@vitidev Тогда в чём смысл проблемы? Если вы не знаете, является ли попадание в LOH проблемой, мне это кажется предждевременной оптимизацией в стиле «а давайте переиспользуем переменную под счётчик цикла»

мне опыт говорит что с ним все плохо
я знаю что операция попадания туда будет частой очень частой
я знаю что он не дефрагментируется
и я не хочу надеятся на GC

уж поверьте знаю.

@vitidev Ну вы вместо этого очень сильно грузите GC

линейные списки для GC — худший вариант

надеюсь, понятно, почему?

ну мс сделали нужный мне метод как Internal. я могу его жахнуть

@vitidev internal они сделали потому, чтобы никто не вызывал его

и вот зря они так сделали

9:55 AM

@vitidev Пользуйтесь официальным API

Это не гарантировано будет работать

И не нужно говорить «я подсмотрел в исходники»

в этом то и проблема
у них написано в доках к методоу

// Adds a lightweight completion action to a task. This is similar to a continuation
// task except that it is stored as an action, and thus does not require the allocation/
// execution resources of a continuation task.

Я всегда из выигрыша двух миллисекунд и сохранения чистой семантики выбираю семантику

@vitidev ага, stackalloc тоже lightweight

@VladD когда ваша операция будет выполняться постоянно и в итоге вылетит OOM вы пересмотрите свое решение

я ловил OOM при свободной памямти из за LOH

только вы уверены, что понимаете, когда его можно вызывать, а когда нет?

@vitidev А вы не пытаетесь управлять GС вручную?

угу. я понимаю как работает этот метод и как бы он щас решил мою проблему

9:58 AM

или там может у вас тонны неуправляемых объектов

@vitidev Честно? Не верю.

Ну и в чём проблема моего метода?

нет. я пытаюсь оптимизировать попадание в LOH
у меня частая операция результаты которой 1000% попадут в LOH и будут его последовательно забивать

а дальше....либо LOH будет нрмально вычищаться либо я получу OOM

скармливаете ему tasks, и у вас нету материализации списка

ну и в конце-концов заведите менеджер списков

@VladD еще раз скажу - я не понимаю как его использовать этот ваш метод

кеш

ну переиспользование списков оно сложнее и неудобнее

10:00 AM

@vitidev Вместо await Task,WhenAll(tasks) пишете foreach (var t in tasks) await t.ConfigureAwait(false)

@vitidev Да, а грязные трюки с GC конечно лучше

Вам выбирать

Я бы ни за что не игрался с GC

ну это мы избавляемся только от When.All
но tasks же уже материализованный список и попадет в LOH

@vitidev И что? А списки у вас кешируются

Проблема решена на корню, и притом чисто

без фигни, которая отпадёт с апдейтом .NET

или превратится в пессимизацию завтра

я бы выбрал тот интернал. но мне его не дают. он бы не дал оверхеда вообще
в кешировании есть проблема. какой размер списка нужен и сколько их держать в кеше
в итоге может быть клиентов 0 но у нас в кеше с 10ок миллионных списков висят и + сколько там мегабайт памяти занятых ничем

@vitidev Сколько раз у вас одновременно происходит вот это всё? Держите только один

Если одновременно обычно 10, держите 10

заведите их сразу правильного размера

если размер динамический, придумайте хорошую эвристику

я не могу знать сколько одновременно. любое место в системе может в любой момент ицициировать отправку сообщений всех клиентов. и я НА УРОВНЕ БИБЛИОТЕКИ не могу знать сколько это будет и не могу завести нужное количество

а значит мне придется создавать держать и по таймеру освобождать если никто не юзает - вот это я и называю "ручное управление GC"

10:05 AM

@vitidev Нет, это не ручное управление GC, это ручная GC.

я лучше уж к интернал пробьюсь. благо это дотнетКОРЕ

управлять GC не нужно, сделаете хуже

@vitidev Ну, жду вас со следующей проблемой, вызванной использованием недокументированных функций

Боюсь, вот из-за таких грязных трюков и возникает OOM на ровном месте

делайте чисто, это окупается всегда

@VladD потому я и говорю что ПЛОХО что они сделали его интернал такой полезный метод. И они же советуют "ну вы там оптимизируйте а то LOH онтакой "

@vitidev Ну stackalloc тоже не даёт оверхеда. Но у него есть другие проблемы.

@vitidev Если они сделали его внутренним, это не просто так. Это чтобы всякие разработчики не дёргали его всегда, думая, что «это ж эффективнее»

Если бы можно было в любой момент и в любых обстоятельствах его дёрнуть, он был бы public

Если у вас нет очень отчётливого понимания, почему он сделан internal, я бы не рекомендовал его использовать

@VladD или просто не посчитали что он будет кому то нужным, ведь есть ContinueWith

10:10 AM

Но вы опытный программист, разберётесь

@vitidev Не думаю.

Если он более эффективный

там же еще написано
// Used internally by ContinueWhenAll() and ContinueWhenAny().

то есть просто вынуждают исопльзовать нужный api связи тасков и не мудрить

Да, используется. А почему его можно использовать именно в ваших условиях?

Какие ограничения он накладывает?

о том что кому тонужно будте мудрить они и не думали. ведь их задача была сделать TPL а не LOH-ами заниматься

@VladD не ограничение. позволяет не создать миллион задач продолжений. а передать миллиону задач 1 обьект подписчик который будет вызван из каждой задачи.

@vitidev Вы почему-то думаете, что в Microsoft сидят клинические идиоты, которые выставили наружу неэффективный метод просто так

Я в такое как-то не очень верю

Мне в жизни приходилось использовать внутренний метод только два раза

Один раз где-то в недрах WPF дёргал подчистку кеша

вы же сами выбираете семантику. семантика на первом месте. TPL это семантика тасков и продолжений. и для них норма материализовать все задачи внутри WhenAll

зачем им думать "а вдруг кто то запустит миллион" если это не относится к семантике.

10:14 AM

Один раз в сетевом клиенте что-то насчёт credentials

@vitidev Относится-относится.

есть еще вариант обернуть func в типа
await func();
counter --

и так я получу миллион делегатов, но не миллион продолжений по идее ведь там будет конечный автомат

но это опять + миллион объектов

@vitidev Ага, и как его await'ить?

Вы сначала сделайте чисто

Потом сделайте грязно

Потом сравните производительность на типичном workflow

tasks.Add(func(client));
-----
Task.Run(async () =>
{
_counter++;
await func(client).ConfigureAwait(false);
_counter--;
});

@vitidev Это понятно, а как дождаться момента, когда counter станет равным 0?

@VladD чисто я давно сделал. частые операции попадают в LOH ибо они частые и 100% туда попадут. теперь оптимизирую

10:19 AM

@vitidev ну сделайте кеширование списков, и сравните

ну под _counter--; проверку сделать. делов то

@vitidev эээ, жульничество какое-то

что сранвить. что я могу сравнить? я не вижу LOH нормально ибо для дотнеткоре нет вменяемых инстурментов. я полагаюсь на опыт
опыт говорит что большой список гарантированно попадет в LOH и что он у меня может быть большим для этого надо не так уж много тасков параллельных.
и что будет 3 попадания в LOH за каждый вызов этого метода. а этот метод будет вызваться очень часто

а что делать в ситуации, если первый таск запустился и отработал, а второй ещё не начал запускаться?

в итоге на 32битке я рискую получить OOM

Андрей NOP

10:21 AM

@VladD неа, в вопросе коллекция ответов. А в ответе ссылка на один следующий вопрос

это в моем трекере учтено

@vitidev «полагаюсь на опыт» = «делаю оптимизацию вслепую»?

до момента WhenAll счетчик не будет учитвыаться

@vitidev в каком трекере?

@VladD ну с LOH я в свое время здорово помучался так что опыт понимания есть. другое дело как быть с тасками что непозволяют так просто

10:23 AM

По моему опыту, оптимизация вслепую = напрасная трата времени и ухудшение кода

который TaskWhenAllTracker что по той ссылке.

@VladD ага. до первого OOM

а потом начнется "ааааа что делать. ааааа"

Проводя низкоуровневую неалгоритмическую оптимизацию, вы обязаны получить доказанное повышение производительности, и покрывать прирост производительности regression-тестами

@vitidev Плавали, знаем.

я уже это проходил. я знаю причину, я знаю как решать. я знаю что такое LOH заранее

а причем тут производительность до OOM

Решается пониманием того, какой ресурс критический, и ручным кешированием его

@vitidev У вас есть простой честный способ решения проблем с ООМ — кеширование. Есть нечестный — заглянуть .NET в потроха и дёрнуть метод, которые они дёргать не рекомендуют.

ну я хочу избежать и кеширвоания. это трата памяти причем довольно часто впустую. а асп.нет при серверном гц и так пугает тратами памяти. и серверный гц гордый ежик
можно выделить 500 метров и освободить память и гц даже не пошевелится

10:26 AM

@vitidev Ну и отлично, а и правда, зачем ей дёргаться?

Это сервер?

Низкое потребление памяти — non-goal

не то чтобы не рекомендуют. простоесть же апи, где важна семантика, а оптимизация вещь особая и ради оптимизации никто в паблик выставлять не собирался

@vitidev Я повторюсь: из оптимизации и сохранения семантики я всегда выбираю семантику. Оптимизация окупается редко, оптимизация без профилирования — практически никогда, чистая семантика — всегда

да. сервер. где может быть совсем мало памяти.
а LOH уходит в своп = тормоза
может быть OOM если 32битность

Я никогда не превращаю логику кода в спагетти, чтобы выиграть 1 кб памяти

Да даже и 100 мб

@VladD именно поэтому они и сделали тот метод интенрнал, а не "его опасно использовать все поломается". просто он нарушает семантику и потому скрыт.

10:29 AM

@vitidev Вы уверены? Или вам так кажется?

Если уверены, вызывайте. Я не рекомендую, но у каждого свой подход

Я всегда держал код чистым, и проблем никогда не было.

@VladD я не телепат но то что это не семантично видно и так

Единственная на моей памяти проблема с памятью решалась (и до сих пор решается) контролированием буферов вручную

Андрей NOP

@Bretbas Focusable?

msdn.microsoft.com/ru-ru/library/…

а часто ли вы делали задачи где массово и быстро рождаете обьекты что попадают в LOH?
у вас как я понял класс обычных клиентских прилжений где подобных вещей нет
вам и оптимизации то ни к чему особо

@АндрейNOP Я тут подумал: если блоки нужно передвигать, то координаты становятся из подробности UI чем-то более серьёзным, и уезжают в VM

@vitidev Это была неуправляемая память

Точнее, обёртка над ней

10:32 AM

@АндрейNOP че то оно особо не помогло. Может быть это особенности RadTimeLine от телерика

@vitidev Ещё как к чему: с камеры летят огромные кадры, которые нужно на лету обработать, показать, пропустить через raytracer, вот это всё.

и память под них быстро заканчивается, если не управлять ей правильно

получается что я могу выделать stackalloc и потом в цикле await сделать и избежать материализации
вот только это дотнеткоре и могу ли я так

а нет. не могу. я же не знаю нужный мне размер

@vitidev Можете. Но тогда упадёте при недостатке стека

Зато overhead нулевой, а Microsoft почему-то, гады, выделяют память в куче

у меня LInkedLIst размер которого не известен. в него могу быть добавлены элементы в момент обхода. хотя конечно я могу игнорировать эти добавленные элементы на этой операции

почему гады. размер стека не бесконечный. а куча побольше

Андрей NOP

@Bretbas зависит от контрола, да. Например, кнопка с Focusable="False" обрабатывает клики мышью, но фокус получить не может ни с клавиатуры, ни с мыши

10:35 AM

@vitidev Именно. Но тут вы понимаете, что метод с нулевым оверхедом имеет побочку.

а вот с LOH они лоханулись со своими 85000. в жава без лоха живут как то

@vitidev Не думаю. Они прекрасно меряют производительность на типичных задачах

Вот кто-то, а Microsoft проводит профилирование перед выпуском фичи

@АндрейNOP Я сделал проще. Просто на ловлю PreviewKeyDown и e.Handled=true и Tab, и все. Не буду заморачиваться

Андрей NOP

@VladD по идее да, но не хотелось бы смешивать основной функционал и возможность перетаскивания. Надо делать обертку, но куда ее помещать? В VM или во View?

@VladD ага. только в каком году ))). многие пишут что времена то изменились

Андрей NOP

10:37 AM

@Bretbas по хорошему, если контрол не должен реагировать никак, то ему надо ставить IsEnabled="False"

@АндрейNOP Нет, как не должен? Мне нужно чтобы он был доступен:)

@АндрейNOP У меня это обычно VM-обёртка

@vitidev Давайте я повторюсь: я использовал их стек так, как было ими задумано и как рекомендуется всё время, и никогда не сталкивался с реальными проблемами.

Андрей NOP

@VladD а что с этим:

17 mins ago, by Андрей NOP

@VladD неа, в вопросе коллекция ответов. А в ответе ссылка на один следующий вопрос

Так что у меня получается их готовить

Андрей NOP

делать ItemsSource="{Binding Answers}", а потом в DataTemplate уже привязываться к Question.Property?

10:40 AM

@АндрейNOP Тогда пусть ответ и следующий вопрос будут иерархически одним и тем же?

а я сталкивался. рождал и освобождал быстро обекты и получил OOM при свободной памяти. решиось изменением обьетов чтобы они не попадали в LOH. (переиспользование было не сильно возможно да и не нужно было)

тут же хочется меньше напрягать сервер

@АндрейNOP Угу, типа того

@vitidev Я никогда не думаю в терминах LOH

Андрей NOP

@VladD Не понятно только что делать тогда с самым верхним уровнем. Фиктивный список ответов делать? Со ссылками на корневые вопросы

Думать в терминах подробностей имплементации — верный путь к проблемам

Если какие-то объекты не коллектятся эффективно, я делаю свой менеджер для них

кеш, повторное использование, вот это всё

я не думаю в терминах «майкрософт лоханулась, их GC не понимает мой паттерн использования»

а нужно ждать пока упадет чтобы признать очевидное? нужно ждать свопов с тормозами чтобы узнать то что и так знаешь?

в обычных задачах я тоже не думаю. Тут же задача где оптимизация важна. В частности я активно избегаю мемори трафика при формировании сообщений

10:42 AM

я думаю в терминах «этот объект не собирается GC, значит я должен собрать его сам»

@VladD вы перегибаете. я думаю в термине "мой случай выходит за рамки "типичных" а значит нужно тюнить"

@vitidev Проблема не у LOH. Проблема у вас. Вам не подходит бесплатный автоматический CG — пишите свой менеджер, делов-то!

@vitidev Нет, вот «тюнить» — это всегда плохо

потому что вы решаете частную проблему одного класса за счёт остальных классов, с которыми GC справляется хорошо

решайте локальные задачи локально

особенно так делать нельзя, если вы библиотека

@VladD вообще то я пришел с вопросом "понятно что будет забиваться LOH и как быть" а не пришел показываь "вот какой я молодец я сделал так". при отсуствиии предложений я решаю как могу

и "а в уверены что лох будет забиваться" это увод в сторону. конечно уверен

@vitidev не, вопрос не про LOH, а про то, что GC не справляется

а почему именно не справляется — это внутренняя подробность

и ответ на такое — кеш и ручное управление

это зависит от конкретного сервера уже. я хочу не зависеть от конктреного сервера.

10:47 AM

@vitidev Тогда делайте ручное управление всегда

будете независимы от сервера

а вот тут общие фразы. потому что для этого нужно как то эвристировать чтобы память зря не занимать. то есть сразу переходим к вопросу "ок кеш. и какой алго кеша придумать чтобы выделенная ранее память зря не простаивала, как решить когда конкретно освободить ее а не держать зря. и сколько выделять чтобы не было "ну нифига себе сколько жрет""
серверный гц вообще не шевелится

я должен сделать пул буферов неизвестных размеров с автоочисткой. звучит хорошо, но какая эвристика должна быть хз

или же пойти в тот метод интернал благо это дотнетКОРЕ, а не дотнет

это в дотнете будет выполнен на любом райнтайме. ав коре как я понял потребует конкретного указанного

для аспнет указывается конкретная версия

и кстати. я могу прсото сделать List на чанках
чет я про него забыл

ну а че я так придираюсь к LOH

habrahabr.ru/post/83929 первый раздел.

@VladD ради интереса попробуйте залить гигабайт в MemoryStream.

11:34 AM

@VladD нус тасками - я просто переделаю класс чтобы он вместо списка держал чанки + вместо WhenALL фореач и так и в LOH не попадет и нагрузка на GC будет в "размер чанка" раз меньше

теперь мне интересен другой вопрос - должен ли я везде использовать Interlocked где подразумевается доступ из разных потков?. тоесть везде везде

2 hours later…

1:08 PM

@vitidev Да, можно и так

обходить его придётся через foreach

тоже такой локальный ограниченный костыль

но и правда, если вам нужно много тасков, почему не завести просто счётчик?

его по идее должно хватить

@vitidev угу, я не дочитал до этого

да, так и надо, это по идее проще всего

@vitidev чанки лучше, чем linked list

можно вообще просто List<List<...<List<T>>...>>

@vitidev Конечно Interlocked! А как иначе?

Ну или mutex, если есть семантика верхнего уровня, большая, чем один инт

1 hour later…

2:29 PM

@VladD линкед лист чанков. хотя это видимо я уже считаю зарпедельное количество коннектов с перебором.

@VladD voliatile. но оказывается что он вообще непонятно зачем существует

разве что перестановку инструкций глушить но он неявный

3:28 PM

Ребят, вот посмотрите. Первое мое приложение на WPF

2

Orders Timetable 2018 by Максим Шилов(bretbas)

1 hour later…

Андрей NOP

4:54 PM

@Bretbas круто!

Но, имхо, бизнесу не нужна красота в таких приложениях, ему нужно удобство использования, интуитивно понятный интерфейс. У вас много лишних нажатий и отвлекающий дизайн.

И дата, кстати, не в российском формате MM/dd/yyyy

Замучаетесь "теток из бухгалтерии" учить пользоваться приложением :)

Но для опыта WPF, конечно, круто. Я лично такое бы не написал, т.к. не люблю и не умею в графический дизайн. У меня бы было всё топорно на стандартных привычных контролах и, по возможности, без лишней анимации и лишних нажатий :)

@Bretbas, раз уж решили разрисовать окошко - надо бы и кастомный заголовок окна сделать :)

чтоб не выделялся/не отличался

3 hours later…

7:48 PM

@Bretbas Для первого приложения офигенно

Ну и не только для первого

« first day (974 days earlier) ← previous day next day → last day (2057 days later) »

Transcript for

Apr '1815

Дискуссии о C#/.NET на русском

Эта комната посвящена обсуждению C#: всё, что не подходит в фо...

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile