Спасибо за статью. Про то, что Instagram как и любое стороннее фотоприложение снимает намного хуже на андроиде - уже давно известно. Но тут все встало на свои места. Очень глубокий материал. Было бы круто увидеть продолжение - если вендоры ответят. Либо обзоры на косяки в поддержке Camera API каждого телефона и как эти косяки были обойдены.
Напрямую с потоками работать не надо — проще использовать асинхронную модель .NET (которая поточность разруливает сама через ThreadPool) и методы сокетов Socket.BeginXxx и EndXxx, либо обновленные методы Socket.XxxAsync. Последние как раз ориентированы на работу с пулом переиспользуемых объектов и должны работать быстрее.
Начать можно отсюда, хорошая статья вплоть до методов BeginXxx/EndXxx и про обновленные методы немножко здесь. Также по ссылке из статьи можете глянуть мою реализацию.
Попробую ответить на каждый пункт:
1. Мне кажется, что написать Take вместо new, а Release вместо потенциального Dispose — это вполне приемлимое усложение в ситуации, когда нам пул нужен. Если про общую архитектуру идет речь — согласен, +(1-2) класса, хотя это тоже не так много.
2. Ошибку можно сделать и просто «бросая» объекты. Может, сложнее, чем с пулом, не спорю, но тема отдельная))
3. Объекты 85к как правило массивы, вполне могут быть неуправляемым блоком памяти и/или фиксированным буфером для череды каких-либо операций. Операция Array.Clear работает быстрее, чем создание такого же огромного массива.
Посмотрите мой пример, там используется объект SocketAsyncEventArgs, который содержит фиксированный буфер памяти для операции с сокетами. И по тестам видно, что очистка этого буфера происходит быстрее, чем создание нового объекта. Конечно, ограничения использования есть и часть их приведена в самом начале статьи.
Нет, поток ничего не должен уметь. Сам пул уходит в ожидание возврата объекта, то есть метод Take гарантированно вернет объект. Суть еще в том, что при адекватном максимальном значении такая ситуация будет редко возникать.
Отвечу на замечания по микрооптимизации. Я согласен с вашим комментарием, в простейшей реализации пула будет достаточно и простого Lock, он хоть и проигрывает в синтетике, но реальное приложение редко будет требовать такого прироста. Моей целью была не реализация наипростейшего пула (на мсдн кстати лежит вполне годная с использованием ConcurrentBag), а демонстрация того, как можно сделать вообще без классических примитивов.
За критику — спасибо.
Именно поэтому я взял слово «атомарная» в кавычки. Ничего страшного действительно не произойдет.
Поток получит свой объект в таком случае при следующем запросе к пулу.
Спасибо за статью. Про то, что Instagram как и любое стороннее фотоприложение снимает намного хуже на андроиде - уже давно известно. Но тут все встало на свои места. Очень глубокий материал. Было бы круто увидеть продолжение - если вендоры ответят. Либо обзоры на косяки в поддержке Camera API каждого телефона и как эти косяки были обойдены.
Кажется, ничего не изменилось…
Начать можно отсюда, хорошая статья вплоть до методов BeginXxx/EndXxx и про обновленные методы немножко здесь. Также по ссылке из статьи можете глянуть мою реализацию.
1. Мне кажется, что написать Take вместо new, а Release вместо потенциального Dispose — это вполне приемлимое усложение в ситуации, когда нам пул нужен. Если про общую архитектуру идет речь — согласен, +(1-2) класса, хотя это тоже не так много.
2. Ошибку можно сделать и просто «бросая» объекты. Может, сложнее, чем с пулом, не спорю, но тема отдельная))
3. Объекты 85к как правило массивы, вполне могут быть неуправляемым блоком памяти и/или фиксированным буфером для череды каких-либо операций. Операция Array.Clear работает быстрее, чем создание такого же огромного массива.
Посмотрите мой пример, там используется объект SocketAsyncEventArgs, который содержит фиксированный буфер памяти для операции с сокетами. И по тестам видно, что очистка этого буфера происходит быстрее, чем создание нового объекта. Конечно, ограничения использования есть и часть их приведена в самом начале статьи.
Отвечу на замечания по микрооптимизации. Я согласен с вашим комментарием, в простейшей реализации пула будет достаточно и простого Lock, он хоть и проигрывает в синтетике, но реальное приложение редко будет требовать такого прироста. Моей целью была не реализация наипростейшего пула (на мсдн кстати лежит вполне годная с использованием ConcurrentBag), а демонстрация того, как можно сделать вообще без классических примитивов.
За критику — спасибо.
Поток получит свой объект в таком случае при следующем запросе к пулу.