Найти - Пользователи
Полная версия: Что быстрее, tuple или sqlite?
Начало » Python для новичков » Что быстрее, tuple или sqlite?
1 2 3
NSkrypnik
Добрый день, всем!!!

У меня один такой маленький вопросик, в принципе могу разобраться сам, но вдруг кто-то навскидку ответит.
В общем есть большой одномерный массив данных, алгоритм получает слово и должен проверять есть ли это слово в массиве. Может кто знает, что будет работать быстрее - создать tuple, и проверять в нем, или же записать этот массив, как таблицу sqlite, и проверять там? Или же разница по времени будет незначительная(массив данных порядка 300-т 400-т слов)?

Всем заранее большое спасибо за ответы.
Всего самого наилучшего!
balu
Попробуй оба варианта. Плюс много будет зависеть от того. как часто делается эта операция, как часто и с какой скоростью добавляются данные в список и т.д. Я бы держал в БД - не надо каждый раз заполнять. Хотя очень много от условий задачи зависит, может и свою процедуру поиска сделал бы, если скорость стандартных средств не устраивает.
clopomor
memcache ще спробуй
igor.kaist
clopomor
memcache ще спробуй
conn=sqlite3.connect(':memory:')
ZZZ
Хм… А я бы подумал в сторону bisect. Просто и быстро.

И это… tuple он для позиционных данных, а для списков всё-таки list.
PooH
300-400 слов? держите их на словаре
test157
PooH
вроде как речь идет о 300-400 тысяч слов

питон начинает тормозить - после нескольких тысяч записей, особенно при поиске и выборке. причем на больших объемах работа замедляется очень сильно (( даже пыха. по старой памяти - по лучше справляется
с большими объемами, но и для нее 400 тысяч всеже многовато. ближе к 100 начинались кокретные тормоза.

вобщем для тебя имхо лучше использовать MEMORY тип таблицы в MySQL сервере. ты создаешь таблицу которая хранится в ОЗУ компьютера, и скороть доступа к данным очень большая + у тебя в руках весь функционал СКУЛ языка, по выборке и обновлению этих данных. но один недостаток - такие данные теряются после рестарта сервера. поэтому если нужна их постоянна сохранность в БД то можно юзать обычные ТАБЛИЦЫ, и для любой современной БД в том числе и для СКУлайт - 400 тысяч записей это небольшой объем (если они конечно не файлы, и каждая строка в таблице не занимает несколько мегабайт) хотя майскул с этой задачей при достаточном кол-ве памяти для индекса - справится куда быстрее.

для примера на обычном комьютере (квад кор 8ГБ памяти) у меня была таблица, в которой было около 100 миллионов строк. таблица не сложная была пару столбоцов интов, и одно поле - строка длиной около 200 симоволов. так вот, поиск по этому полю при помощи LIKE занимал около 5 секунд. под индекс конечно был выделен значимый размер оперативки.
ZZZ
Однако set оказался лучше… И нечего парится с СУБД, если нужно всего лишь узнать есть слово там, или нет.

# coding: utf-8

import bisect
import random
import timeit

chars = u'qwertyuiopasdfghjklzxcvbnm_01234567890'

def create_word():
w = u''
for n in range(random.randint(3, 13)):
w += random.choice(chars)
return w


def create_list_of_words(count_of_words):
l = []
for i in xrange(count_of_words):
bisect.insort(l, create_word())
return l


l = create_list_of_words(500000)

setup = '''
from __main__ import create_word, l
import bisect
w = create_word()
bisect.insort(l, w)
'''
stmt = '''
bisect.bisect(l, w)
'''
timer = timeit.Timer(stmt, setup)
print (sum(timer.repeat(100, 1000)) / 100) / 1000 # среднее значение времени поиска


def create_set_of_words(count_of_words):
s = set()
for i in xrange(count_of_words):
s.add(create_word())
return s

s = create_set_of_words(500000)

setup = '''
from __main__ import create_word, s
import bisect
w = create_word()
s.add(w)
'''
stmt = '''
w in s
'''
timer = timeit.Timer(stmt, setup)
print (sum(timer.repeat(100, 1000)) / 100) / 1000
P.S. Не пугайтесь, выполняется долго – создание такого количества слов, это вам не два к двум прибавить…
P.P.S. Да, пример с set не совсем корректный, потому что он не держит повторяющихся слов… Но я не думаю, что их не будет в реале…
PooH
test157
PooH
вроде как речь идет о 300-400 тысяч слов
Прошу прощения, не сообразил, так тысячи не сокращают :) Можно еще попробовать shelve
PooH
test157
питон начинает тормозить - после нескольких тысяч записей, особенно при поиске и выборке. причем на больших объемах работа замедляется очень сильно (( даже пыха. по старой памяти - по лучше справляется
с большими объемами, но и для нее 400 тысяч всеже многовато. ближе к 100 начинались кокретные тормоза.
Вот не надо ля-ля. Использовал в одноразовых скриптах, никаких тормозов, лишь бы памяти для данных хватило. Я не смотрел исходники dict, но скорее всего он реализован через бинарное дерево, так что поиск в нем должен иметь сложность O(log n). Вот если память в системе исчерпается, тады ой, хруст винта и задумчивость системы.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB