доступными по http

Ну это ладно

@Exie42 говоря о сравнительной характеристике, ты таки располагаешь объективными данными или просто новости читать любишь?

Дампы по сети гуляют

Ну это ладно

не, в смысле, в свободном доступе https://habrahabr.ru/post/70330/

С 2012 года

не, в смысле, в свободном доступе https://habrahabr.ru/post/70330/

Я в курсе. Тогда у многих увели

окок, сорри!

Поэтому простительно

Ну а так-то рамблеру спасибо за нгинх

жаль что не сдохло сразу

царт очень крутой специалист в python, но в остальном лучше не спрашивать

удел гения =)

от царта слышу

?

Узнаю старый добрый чят.

кстати, асинкодрочеры еще не хвастались https://twitter.com/squeaky_pl/status/826415928539746304 ?

А чо там?

Хрень жн

ну лям рпс!111одиннацдать на петони!111

Либа на сях уже 3 года как есть, биндинги ко 2му питону тоже

(смешной факт: вся работа практически сделана силами С, но в хэштегах питон и асинкио)

(смешной факт: вся работа практически сделана силами С, но в хэштегах питон и асинкио)

дадада, тоже насмешило

Раст 2.6rps

я люблю питон, но в этом проекте он просто рядом свечку держит

там еще и парсер хттп с ассемблерными вставками, насколько я помню

picohttpparser вроде, да

хотя там вроде не асм вставки, а просто SSE 4+ используется

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

....и бенчмарк одним потоком

Ну а так-то рамблеру спасибо за нгинх

Там спасибо одному единственному сысоеву. Цитируя Zart, вся работа была сделана Игорем, но в тэгах почему-то Рамблер :)

Несмотря на неплохие показатели в синтетических тестах, на реальных серверах Dropbox использование Pyston позволило добиться лишь ускорения кода на 10%, что значительно меньше ожидаемого (планировалось добиться повышения производительности как минимум в два раза).

всем бенчмаркерам посвящается

Pyston - всё? :)

"В итоге, более реалистичным путём оптимизации в Dropbox стала переработка кода, требующего высокой производительности, на других языках, таких как Go." Щас go'вноёбы заполонят весь инет своими воплями :)

Го норм. В нём только тулинг дерьмо

а еще rust

растоёбы, го'вноёбы, питоноёбы

у них там содомия

раст - это хорошо

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

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

GO

GO

неканает

а что за тулинг у раста?

нормально?

GO

Го какой то странненький. Пишешь вроде норм, но не покидает ощущение что что то не то.

раст и го оба какие-то нихуя не лаконичные

"The fact that we *have* -stable trees in our dev repo is kind of an aberration compared to most of the rest of the universe." фрюшники сами охуевают от того что навертели 8)

А чо где.

https://wiki.freebsd.org/GitDrawbacks

там попутно рассказывается о том, что они свн сами криво юзают

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

270 гиг - достаточно крупнокалиберный?

https://blogs.msdn.microsoft.com/visualstudioalm/2017/02/03/announcing-gvfs-git-virtual-file-system/

"even a simple “git status” takes almost 10 minutes to run. "

"For our repository, enabling Watchman integration has made Mercurial's status command more than 5x faster than Git's status command. Other commands that look for changed files--like diff, update, and commit—also became faster."

Всем привет. Есть pyQT5, в нем горизонтальный слайдер, к которому привязана функция, которая перерисовывает картинку в главном окне. Суть в том что при передвижении слайдера перерисовка дико лагает. Как избавиться от лага, может задержку как то можно поставить? Работа с картинкой через пиллоу идёт, но если запускать обработку картинки отдельно то всё ок.

вместо принудительной перерисовки там разве нет инвалидации?

А вот и слово для гугления. Сейчас гляну.

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

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

"even a simple “git status” takes almost 10 minutes to run. "

ты дальше дочитай

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

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

Второе больше подходит, спасибо, буду копать.

"which virtualizes the file system beneath your repo and makes it appear as though all the files in your repo are present, but in reality only downloads a file the first time it is opened." это они опять меркуриал догоняют

"To solve this problem we created the remotefilelog extension for Mercurial. This extension changes the clone and pull commands to download only the commit metadata, while omitting all file changes that account for the bulk of the download. When a user performs an operation that needs the contents of files (such as checkout), we download the file contents on demand using Facebook's existing memcache infrastructure. This allows clone and pull to be fast no matter how much history has changed, while only adding a slight overhead to checkout."

<deb33601> Zart, печально что ты джангу не юзаешь <Zart> чо?

охуели они там 8(

:D

любое говно уровня "майкрософт ускорили гит" автоматически приравнивается к фразе "X ускорили Y для своего кейса"

у дропбокса еще печальней - они и для своего кейса не смогли ускорить (

https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-git-and-some-back-story/ гм... любопытно

"We’ve seen multi-hour builds drop sometimes to minutes" - про их облачные билды

вообще круто решать проблемы такого масштаба... прямо как сапёр - ошибиться можно лишь раз 8)

вообще круто решать проблемы такого масштаба... прямо как сапёр - ошибиться можно лишь раз 8)

как ёрик из гитлаба недавно, да %)

хуяк-хуяк продакшену

олсо это очередной пост, подтверждающий тезис о том что субмодули гита - сраное говно

Мне вообще удивительно - как в микрософте решились использовать GIT, если он приличное время вообще не работал под windows?

ну у них же там не только деды сидят, работающие только там с 2000х

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

постоянно нанимают новых и т.п., а какой современный девелопер не умеет в гит?

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

уж точно не для гита

уж точно не для гита

я глупо пошутил просто :(

Почему они Меркуриал не попробовали? Или попробовали и где то есть статейка - "гит выиграл у меркуриал (c) MS"?

ахз. в постах выше меркуриал упомянут

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

жаль что фб не опубликовал размеры своей репы

https://twitter.com/feross/status/459259593630433280 - 54гб это было в гит копии 3 года назад

"I am working on a game where head is 1TB. On top of code and assets this size includes a few full builds and a full set of game-ready data (the data build process takes something ridiculous like 7 hours, so that's done on a server and it checks the result in). All in the same repository. 1TB is rather a lot. My previous record was 300GB and even that seemed a bit much. But it is very convenient having everything in one place, including all the stuff that you only need occasionally but is handy to have to hand, such as old builds of the game that you can just run in situ and installers for all the tools. (I don't know what the entire repository size must be like, but many of the larger files have a limited history depth, so it's probably less than 5-10TB. So not exactly unimaginable, though I'm sure buying that much server-grade disk space - doubtless in duplicate - might cost more than I think.)" в терминах файлового размера ассет репы спокойно уделывают репы кода

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

Ассеты и билды в репе - они определенно doing it wrong

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

Для таких вещей есть же хранилища артефактов

копия поста про 1тб выше была про перфорс, если что

который именно для артефактов

Ну тогда при чем тут гит

ну тут речь про использование scm на репах особо крупных размеров (по колву гигабайт, файлов и версий)

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

Угу, начинают вылезать сабмодули