Чтобы скрипт быстрее

Ты не тот язык для задачи такой выбрал. Если тебе нужна производительность возьми C и т.д. P.S. можешь написать расширение на C для Python и использовать его.

Ты тоже. Ему просто надо перестать индусской хернёй страдать.

1) Если Python 2 - используй xrange 2) Формируй большой буфер в памяти и большими блоками пиши в файл - это точно поможет, любой язык тормозит если побайтно писать в файл

append не очень быстро... надо нечто, что выделит память сразу «под всё» и ты просто кладешь в элементы свои значения

Как вариант

import numpy
import random
import time

def write(path, mode, size):
    with open(path, mode) as file:
        file.write( (numpy.random(size) * 255).astype(numpy.int32).tobytes() )

start_time = time.time()
write("file1", "ab", 20000)
t1 = time.time()
print("dt1=" + str(t1-start_time))

write("file2", "ab", 20000)
t2 = time.time()
print("dt2=" + str(t2-t1))

write("file3", "ab", 1000)
t3 = time.time()
print("dt3=" + str(t3-t2))

write("file4", "ab", 200000)
t4 = time.time()
print("dt4=" + str(t4-t3))

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

что бы

в моём numpy нет numpy.random(size)
точно код правильный? и да, numpy просто ради теста, но надо без него

Подскажите пути повышения производительности, но без платформозависимых /dev/urandom и нестандартных библиотек

Очевидно же. Go.

в моём numpy нет numpy.random(size)

with open('file7', 'ab') as f7:
    f7.write(numpy.random.randint(256, size=200_000, dtype='uint8').tobytes())
t7 = time.time()
print(f'dt7={t7-t6}')

На два порядка быстрее, однако.

Rust

ну да ну да... эх.

Так а чем тебе сторонние либы не угодили?

Вот подмывало дать пример с numpy, надеюсь numpy достаточно стандартная библиотека? :) Оно кстати скорее всего внутрях создает сразу большой массив и заполняет, и небось на Си.

Я не себе пишу, юзеру еще надо будет numpy ставить, там проблема

Если 3.6, то secrets.token_bytes, иначе os.urandom

А, собственно, настолько ли это большая проблема? Подтянуть numpy как зависимость хоть pip-м, хоть (для линухов) apt/rpm - не должно быть проблемой, в репах он таки есть же. Так что если планируется много числодробления - я таки серьёзно задумался бы о numpy

Подтянуть numpy как зависимость хоть pip-м

вы таки думаете там есть интернет? эх.

положить в проект, вырвать нужный кусок и положить в проект

Включить в дистрибутив же. Вангану что платформа, на которой оно должно работать таки задана заранее, не?

Да не нужны там ни платформа ни дистрибутив, юзеру просто надо быстро создать десяток рандомных файлов заданного размера и всё на этом. Скрипт был бы вариантом, а «дистрибутив» это уже перебор

А что, проблема закинуть скрипт в каталог, и туда же - каталог с numpy?

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

Ну, тогда - перебор, да. С другой стороны - думаю, производительность тут тоже - скорее «спортивный интерес», верно?

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

os.urandom, раньше когда-то использовал ssl.RAND_pseudo_bytes

os.urandom

anonymous, Leron, самое то, что надо!

Пиши не по 1му байту в файл, а как уже сказали - набивай буфер размером хотя бы 64 тыщ байт (64Кб) например в строку, а потом уже эту строку сбрасывай в файл.

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

Писать на ЯП и выкинуть питон