我有一個包含數字的文本檔案，如下所示：

[mpz(0), mpz(0), mpz(0), mpz(0), mpz(4), mpz(54357303843626),...]

是否存在將其直接決議為整數串列的簡單方法？目標資料型別是 mpz 整數還是普通 python 整數都沒有關系。

到目前為止我嘗試過的作業是純決議（注意：目標陣列y_val3需要提前用零初始化，因為它可能比文本檔案中的串列大）：

text_file = open("../prod_sum_copy.txt", "r")
content = text_file.read()[1:-1]
text_file.close()
content_list = content.split(",")
y_val3 = [0]*10000
print(content_list)
for idx, str in enumerate(content_list):
    m = re.search('mpz\(([0-9] )\)', str)
    y_val3[idx]=int(m.group(1))
print(y_val3)

盡管這種方法有效，但我不確定這是否是最佳實踐，或者是否存在比普通決議更優雅的方法。

為了方便起見：這是 GitHub 上的原始文本檔案。注意：這個文本檔案可能會在未來增長，這會帶來性能和可伸縮性等方面的影響。

uj5u.com熱心網友回復：

我嘗試從人類可讀的角度和性能的角度來看一個更優雅的解決方案。

注意事項：

• 這里發生了很多事情
• 我沒有原始檔案，因此下面的數字與您可能在設備上獲得的任何數字都不匹配
• 嘗試對所有不同部分進行基準測驗的作業太多，因此我嘗試專注于幾個最大的組件

下面的突破和時間似乎在幾種方法中顯示了一個數量級的差異，因此它們可能仍可用于衡量計算作業量的水平。

我的第一個方法是嘗試測量檔案讀/寫添加到行程中的開銷量，以便我們可以探索有多少計算作業集中在資料處理步驟上。

為此，我創建了一個函式，其中包含檔案讀取并測量整個程序，端到端查看我的迷你示例檔案需要多長時間。我是%timeit在 Jupyter 筆記本中使用的。

然后我將檔案讀取步驟分解為它自己的函式，然后%timeit僅用于資料處理步驟以幫助向我們展示：

• 檔案讀取與原始方法中的資料處理使用了多少時間
• 在改進的方法中資料處理方法使用了多少時間。

原始方法（在函式中）

import re

def original():
    text_file = open("../prod_sum_copy.txt", "r")
    content = text_file.read()[1:-1]
    text_file.close()
    content_list = content.split(",")

    y_val3 = [0]*10000

    for idx, element in enumerate(content_list):
        m = re.search('mpz\(([0-9] )\)', element)
        y_val3[idx]=int(m.group(1))
    return y_val3

我假設我非常短的示例資料的大部分處理時間只是用于打開磁盤上的檔案、將資料讀入記憶體、關閉檔案等的時間。

%timeit original()
140 μs ± 10.2 μs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

將讀取檔案與資料處理方法分開

這種方法包括對檔案讀取程序的微小改進。時序測驗不包括檔案讀取程序，所以我們不知道那個微小的變化對整個程序的影響有多大。.close()作為記錄，我通過將讀取程序封裝在背景關系管理器（在后臺處理關閉）中消除了對該方法的手動呼叫，with因為這是讀取檔案的 Python 最佳實踐。

import re

def read_filea():
    with open("../prod_sum_copy.txt", "r") as text_file:
        content = text_file.read()[1:-1]
        return content

content = read_filea()
print(content)
def a():
    y_val3 = [0]*10000
    content_list = content.split(",")
    for idx, element in enumerate(content_list):
        m = re.search('mpz\(([0-9] )\)', element)
        y_val3[idx]=int(m.group(1))
    return y_val3

By timing just the data processing portion, we see that it appears as though our prediction that file read (IO) plays a big component in this simple test case. It also provides us with an idea for how much time we should expect to take for just the data processing portion. Let's look at another approach to see if we can trim that time down a bit.

%timeit read_filea()
21.5 μs ± 185 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

Simplified Data Processing Approach (and Separate Readfile)

Here we will try to use some Python best practices OR Python tools to cut down on the overall time, including:

• list comprehension
• 使用該re.findall()方法來消除對re.search()函式的一些直接和重復呼叫以及對m.group()方法的直接和重復呼叫（注意：findall 可能會在后臺執行一些操作，老實說，我不知道我們是否會避免它有好處）。但我發現這種方法的可讀性要高于原始方法。

讓我們看一下代碼：

import re

def read_fileb():
    with open("../prod_sum_copy.txt", "r") as text_file:
        content = text_file.read()[1:-1]
    return content

content = read_fileb()

def b():
    y_val3 = [int(element) for element in re.findall(r'mpz\(([0-9] )\)', content)]
    return y_val3

這種方法的資料處理部分比原始方法中的資料處理步驟快了大約 10 倍。

%timeit b()
2.89 μs ± 210 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)  

標籤：

上一篇：ReactNative專案使用簡化的布爾運算式運行較慢

下一篇：決議換行符終止的編程語言