Struktur Data Optimal untuk API kita sendiri

10

Saya pada tahap awal menulis mode utama Emacs untuk jaringan Stack Exchange ; jika Anda menggunakan Emacs secara teratur, ini pada akhirnya akan menguntungkan Anda.

Untuk meminimalkan jumlah panggilan yang dilakukan ke Stack Exchange API (dibatasi 10.000 per IP per hari) dan hanya menjadi warga negara yang secara umum bertanggung jawab, saya ingin menyimpan informasi yang saya terima dari jaringan dan menyimpannya dalam memori, menunggu untuk diakses lagi. Saya benar-benar terjebak dengan struktur data untuk menyimpan informasi ini.

Jelas, itu akan menjadi daftar. Namun, seperti halnya struktur data apa pun, pilihan harus ditentukan oleh data apa yang sedang disimpan dan bagaimana data itu akan diakses. Apa, saya ingin dapat menyimpan semua informasi ini dalam satu simbol seperti stack-api/cache. Jadi, tanpa basa-basi, stack-api/cacheadalah daftar kerucut dikunci oleh pembaruan terakhir:

`(<csite> <csite> <csite>)

dimana <csite>akan berada

(1362501715 . <site>)

Pada titik ini, semua yang kami lakukan adalah mendefinisikan daftar asosiasi sederhana . Tentu saja, kita harus melangkah lebih dalam .

Masing <site>- masing adalah daftar parameter API (unik) diikuti oleh daftar pertanyaan:

`("codereview" <cquestion> <cquestion> <cquestion>)

Masing <cquestion>- masing , Anda dapat menebaknya, merupakan kontra dari pertanyaan dengan waktu pembaruan terakhir mereka:

`(1362501715 <question>) (1362501720 . <question>)

<question>adalah kontra questionstruktur dan daftar jawaban (sekali lagi, disetujui dengan waktu pembaruan terakhir mereka ):

`(<question-structure> <canswer> <canswer> <canswer>

dan `

`(1362501715 . <answer-structure>)

Struktur data ini kemungkinan paling tepat digambarkan sebagai pohon, tetapi saya tidak tahu apakah ada cara yang lebih baik untuk melakukan ini mengingat bahasanya, Emacs Lisp (yang tidak jauh berbeda dari Lisp yang Anda kenal dan cintai sama sekali ) . Kerucut eksplisit kemungkinan tidak perlu, tetapi membantu otak saya melilitnya dengan lebih baik. Saya cukup yakin <csite>, misalnya, hanya akan berubah menjadi

(<epoch-time> <api-param> <cquestion> <cquestion> ...)

Kekhawatiran:

  • Apakah menyimpan data dalam struktur yang berpotensi besar seperti ini memiliki trade-off kinerja untuk sistem? Saya ingin menghindari penyimpanan data asing, tapi saya sudah melakukan apa yang saya bisa dan saya tidak berpikir set data yang besar di tempat pertama (untuk penggunaan normal) karena itu semua hanya teks yang dapat dibaca manusia dalam proporsi yang wajar. (Saya berencana menyisihkan data lama menggunakan waktu di bagian atas daftar; masing-masing mewarisi waktu pembaruan terakhir dari anak-anaknya dan seterusnya di bawah pohon. Sejauh mana pemusnahan ini harus dilakukan: saya tidak Tentu.)
  • Apakah menyimpan data seperti ini memiliki trade-off kinerja untuk apa yang harus menggunakannya? Artinya, apakah pengaturan dan pengambilan operasi akan berkurang dari ukuran daftar?

Apakah Anda punya saran lain untuk seperti apa struktur yang lebih baik?

Sean Allred
sumber
Saya memberi ini +1 karena saya benar-benar menginginkan mode ini
Daniel Gratzer
@ Jozefg Saya benar-benar menginginkannya juga — magang ini telah menyedot sebagian besar waktu saya, tetapi begitu sekolah dimulai, kemajuan lebih lanjut harus dibuat .
Sean Allred
Saya sangat senang hanya menginstal plugin browser yang memungkinkan saya menggunakan Emacs untuk mengisi konten kotak teks. Apakah Anda akan membuat Emacs mengerti markup Wiki dan menampilkan teks yang diformat?
kevin cline
@kevincline Tidak, idenya adalah ia hanya akan melakukan tugas utilitarian: arsip pertanyaan lokal; pengeditan kode tingkat lanjut (beralih ke mode utama kanan, mirip dengan org); menyisipkan <!-- language: blah>jika perlu (tergantung pada mode penyuntingan kode yang dilakukan); hal-hal seperti itu. Lihat README di GitHub untuk info lebih lanjut, dan merasa sangat welcome untuk menyarankan fitur. Semakin banyak saya tahu tentang ini sebelumnya, semakin baik itu dapat dirancang. sunting belum lagi emacs keybindings;)
Sean Allred

Jawaban:

1

Emacs lisp tidak dioptimalkan untuk pemrosesan data; Anda mungkin merasa menguntungkan untuk menggunakan Common Lisp untuk engine dan Emacs hanya untuk presentasi.

Bahkan jika Anda memutuskan untuk tetap menggunakan Emacs Lisp, saya sarankan Anda menggunakan data terstruktur ( eieio) alih-alih daftar, dan tabel hash bukan daftar.

sds
sumber