1. 程式人生 > >系統技術非業餘研究 » vanilla_driver最高效的讀檔案行的方法

系統技術非業餘研究 » vanilla_driver最高效的讀檔案行的方法

vanilla_driver是Erlang內建的驅動,用於高效讀取檔案控制代碼或者檔名,官方的文件沒記載.

我來挖掘下:

[email protected]:~# cat >>hello.txt
hello
world
CTRL+D
[email protected]:~# erl
Erlang R13B04 (erts-5.7.5)  [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false]

Eshell V5.7.5  (abort with ^G)
1>  erlang:open_port("hello.txt", [stream,line, in,eof]).
#Port<0.498>
2>  flush(). 
Shell got {#Port<0.498>,{data,{eol,"hello"}}}
Shell got {#Port<0.498>,{data,{eol,"world"}}}
Shell got {#Port<0.498>,eof}
ok
3> 

高效無毒!

Post Footer automatically generated by wp-posturl plugin for wordpress.

相關推薦

系統技術業餘研究 » vanilla_driver高效檔案方法

vanilla_driver是Erlang內建的驅動,用於高效讀取檔案控制代碼或者檔名,官方的文件沒記載. 我來挖掘下: [email protected]:~# cat >>hello.txt hello world CTRL+D [email prot

系統技術業餘研究 » 檢視Erlang執行期內部狀態的方法(基於R13B04)

erts_debug:get_internal_state是用來獲取Erlang執行期內部資訊的主要手段. 但是這個功能是用來給開發人員或者說需要了解系統內部細節的場合, 比如說系統調優. 在R13B04可以使用的選項有: 1. reds_left 2. node_and_dist_referen

系統技術業餘研究 » Linux下如何知道檔案被那個程序寫

晚上朔海同學問: 一個檔案正在被程序寫 我想檢視這個程序 檔案一直在增大 找不到誰在寫 使用lsof也沒找到 這個問題挺有普遍性的,解決方法應該很多,這裡我給大家提個比較直觀的方法。 linux下每個檔案都會在某個塊裝置上存放,當然也都有相應的inode, 那麼透過vfs.write我們就可以知道

系統技術業餘研究 » 2017升的快的幾個資料庫無責任點評

ItPub寫的文章“2017 年度 DB-Engines 資料庫冠軍得主:PostgreSQL 封王!”, 點選 這裡 進一步閱讀 升的最快的幾個資料庫,我簡單的無責任點評: PG資料庫是很老的資料庫,不過這幾年冉冉升起,因為是學院派的,有很好的學術和智力的支援,一直以來在資料庫的體系結構,程式碼

系統技術業餘研究 » 快的Erlang http hello world 伺服器調優指南 (20Khttp短連結請求/S每桌面CPU)

erl的虛擬機器有2種方式 plain版本的和smp版本的。 smp版本由於鎖的開銷相比要比plain版本的慢很多。而32位機器由於記憶體訪問比64位的少,也會快出很多。所有我選擇在32位的linux系統下調優這個httpd伺服器。這個伺服器就是實現個簡單的功能,在browser下返回hello

系統技術業餘研究 » 調查使用者空間程式某函式常呼叫路徑

在做系統調優或者調查效能問題的的時候,比如說調查一個鎖的效能問題。 這把鎖的程式碼會有很多路徑會呼叫, 我們可以在鎖的地方設個probe點,但是我們無法知道那個路徑是最經常呼叫的。 所以我就寫了個stap指令碼來解決這個問題,程式碼在RHEL 5.4/6下都除錯沒有問題的。 $ cat >

系統技術業餘研究 » Erlang R15大的賣點Native Process

R15最激動人心的東西就是這個Native Process,請參看Rickard Green寫的Future Extensions to the Native Interface:看 這裡 我來blabla下。 做過Erlang規模程式的人都知道有個痛, Erlang的公平排程引起的痛。 舉個例子

系統技術業餘研究

ItPub寫的文章“2017 年度 DB-Engines 資料庫冠軍得主:PostgreSQL 封王!”, 點選 這裡 進一步閱讀 升的最快的幾個資料庫,我簡單的無責任點評: PG資料庫是很老的資料庫,不過這幾年冉冉升起,因為是學院派的,有很好的學術和智力的支援,一直以來在資料庫的體系結構,程式碼

系統技術業餘研究 » MySQL資料庫架構的演化觀察

MySQL資料庫架構的演化觀察 December 14th, 2017 Categories: 資料庫 Tags: mysql

系統技術業餘研究 » inet_dist_connect_options

Erlang 17.5版本引入了inet_dist_{listen,connect}_options,對於結點間的互聯socket可以有更精細的控制,RPC的時候效能可以微調: raimo/inet_tcp_dist-priority-option/OTP-12476: Document ke

系統技術業餘研究 » 推薦工作機會

最後更新時間:2014/11/28 請賜簡歷至:[email protected], 感謝您對加入我們公司有興趣,我們希望能早日和您共事。 以下幾個職位1年內有效,歡迎內部轉崗:
 資深資料工程師 公司:阿里(核心系統資料庫組) 工作地點:杭州(西溪園區) 崗位描述: 分析雲服務產生的海

系統技術業餘研究 » 新的工作和研究方向

和大家更新下: 做了將近8年資料庫後,我的工作和研究方向將會延伸到虛擬化和計算相關的雲服務,希望能夠和大家一起進步,Happy New Year! 預祝大家玩得開心! Post Footer automatically generated by wp-posturl plugin for w

系統技術業餘研究 » 叢集引入inet_dist_{listen,connect}_options更精細引數微調

Erlang 17.5版本引入了inet_dist_{listen,connect}_options,對於結點間的互聯socket可以有更精細的控制,RPC的時候效能可以微調: raimo/inet_tcp_dist-priority-option/OTP-12476: Document ke

系統技術業餘研究 » Erlang 17.5引入+hpds命令列控制程序預設字典大小

Erlang 17.5釋出引入控制程序預設字典大小的命令列引數: Erlang/OTP 17.5 has been released Written by Henrik, 01 Apr 2015 Some highlights of the release are: ERTS: Added co

系統技術業餘研究 » inet_dist_listen_options

Erlang 17.5版本引入了inet_dist_{listen,connect}_options,對於結點間的互聯socket可以有更精細的控制,RPC的時候效能可以微調: raimo/inet_tcp_dist-priority-option/OTP-12476: Document ke

系統技術業餘研究 » 老生常談: ulimit問題及其影響

ulimit最初設計是用來限制程序對資源的使用情況的,因為早期的系統系統資源包括記憶體,CPU都是非常有限的,系統要保持公平,就要限制大家的使用,以達到一個相對公平的環境。以下是典型的機器預設的限制情況: $ ulimit -a core file size (blocks,

系統技術業餘研究 » 求賢帖

原創文章,轉載請註明: 轉載自系統技術非業餘研究 本文連結地址: 求賢帖 作為一個優秀的工程師,你其實不缺少才華,你缺少的是神一樣的隊友、充滿挑戰的世界級技術難題,和一個可以施展自己才華的大舞臺。加入阿里核心系統資料庫開發團隊吧,你缺的這裡都有。來吧,戳這裡,給我們見識你的機會:http://b

系統技術業餘研究 » Erlang R16B03釋出,R17已發力

Erlang R16B03釋出了,通常03版本是bug fix版本,進入生產版本,官方的說明如下: OTP R16B03 is a service release with mostly a number of small corrections and user contributions. B

系統技術業餘研究 » Erlang R13B04 Installation

R13B04後erlang的原始碼編譯為了考慮移植性,就改變了編譯方式,以下是官方wiki上的安裝文件: 1. Cloning Here are the basic steps to build Erlang/OTP in the Git repository. Start by cloning:

系統技術業餘研究 » Understanding Linux CPU Load 資料彙總

最近關注線上CPU load的人挺多,很多人覺得load太高系統就有問題,就想各種辦法來折騰。其實在我看來load只是系統CPU執行佇列的在執行程序數的近似值, 如下圖: 對於Unix發展的初期,機器的效能比較差,CPU核數也少,參考意義比較大。現在的機器都是非常強悍的,CPU,記憶體,IO各個