Roman K

Те туторы в которих все в куче - не смотри
Вторые туторы следуют питон дзену

print('lol')

В 3-ем питоне скобки нужны.

У меня аналогичный аппарат, Atom + 1 гб памяти
Долго перебирал и тестировал дистрибутивы.
Основная задача была подобрать нетребовательный дистрибутив к железу
(в основном работа в терминале и браузере)
Собственно список лидеров по убывающей:
Debian 8.5 Mate
Xubuntu
Mint XCFE
Mint Mate
Mint Cinamon

На большинстве (всех?) современных ОС получение времени - это функция ядра. Следовательно для пользовательского процесса в userspace это требует ровно один вызов в ядро, который представляет собой syscall, то есть программное прерывание. На стороне ядра код обычно тривиальный и заключается в получении значения переменной, в которой хранится время (эта переменная инкрементируется из обработчика прерывания таймера), и возврате этого значения через sysret, то есть возврат из прерывания. Поэтому основные временные затраты сводятся к исполнению syscall/sysret и сохранению/восстановлению контекста пользовательского процесса при входе/выходе в/из ядра.
От единиц измерения (нано/мирко/милли) скорость вызова практически не зависит. Конвертация одних единиц в другие происходит на стороне пользовательского процесса, за это отвечают библиотеки и окружение конкретного языка, но эти вычисления составляют всего несколько машинных инструкций и не вносят значительный вклад общее время вызова.

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

В Windows стандартные механизмы GetSystemTime и GetTickCount выдают время только с миллисекундной точностью. А таймер высокого разрешения QueryPerformanceCounter предназначен только для измерения временных интервалов, его абсолютное значение не имеет смысла.

Историческая справка: В реальном режиме работы x86 до тех пор, пока BIOS владеет аппаратным прерыванием таймера и таймер настроен по умолчанию (его еще можно перенастраивать), то есть с интервалом в 55ms и частотой в 18.2 герц, на каждый тик таймера инкрементируется четырехбайтное значение по абсолютному адресу 0:046C. Так что пользовательская программа (термин процесс тут не совсем применим) может получить значение времени мгновенно простым считыванием этого значения из памяти без каких-либо вызовов.
Стоит отметить, что данный функционал не имеет никакого отношения к DOS или какой-либо ОС вообще, а прошит в BIOS любого x86-совместимого (даже современного) компьютера и действителен каждый раз при загрузке машины вплоть до момента перевода процессора в защищенный режим в момент загрузки ядра современной ОС.

за время отвечает микросхема, которая постоянно хранит текущее значение.
Получить текущее время с наносекундами или с микросекундами - совершенно одинаковые затраты.
Вопрос в том, что вы подразумеваете под "слишком часто", поскольку вы можете получать не совсем корректные показатели.

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

SELECT * FROM tablename WHERE id in (4, 23, 43)

from collections import Counter

dct = {
        u'DC963983-0B06-47D4-8E09-9D12C98FEEE4': 3,
        u'DC963983-0B06-47D4-8E09-9D12C98FEEE4': 3,
        u'D2AEE06F-B0BF-41E9-8646-93F7B852F357': 6
    }

values = dct.values()
counter = Counter(values)

print(dict(counter))

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

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

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

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

С вами все так, просто приоритеты расставлены пока что таким образом, что вы переписываете.

postgresql