第5章 ガ－ベージコレクション
プログラムの実行時イメージ 突然だが、本章を始めるに先立ち、プログラム実行時のメモリ空間の状態につ いて予習をしておこうと思う。この章ではコンピュータの低レベルな部分にか なり踏み込んでいくことになるので、あらかじめある程度の知識を仕入れてお かないと太刀打ちできないのだ。それにこの後の章になればいずれ必要になっ てくる。ここで一回やってしまえば後が楽だ。 セグメント 一般的なCプログラムではメモリ空間の中に以下の部分を持つ。 テキスト領域 スタティック変数やグローバル変数の置場 マシンスタック ヒープ テキスト領域はコードが置いてあるところ。二番目は見ての通り。マシンスタッ クには関数の引数やローカル変数が積まれる。ヒープはmalloc()で割り当てて もらうところだ。 三つめのマシンスタックについてもう少し話そう。マシン「スタック」と言う くらいだから当然スタック構造をしている。つまり
Promiseについて0から勉強してみた - Qiita
ES6を使う機会がありそうで、Promiseについて全然知らなかったので、実際に書きながら勉強してみたときのメモ。 なお、以下を参考にさせて頂きました。 0から勉強する時でもとても分かりやすかったです。 JavaScript Promiseの本 環境 Node.js v4.2.2 Promiseとは 非同期処理を操作できる 非同期処理の成功時(resolve)、失敗時(reject)の処理を明示的に書くことが出来る 非同期処理を平行・直列に実行させることが出来る とりあえずやってみる とりあえず、参考にさせて頂いたサイトのコードを書いてみました。 function asyncFunction() { // Promiseオブジェクトを返却する.処理成功時にはresolveが呼ばれる return new Promise(function (resolve, reject) { setTim
async/await 入門（JavaScript） - Qiita
はじめに 今更ですが、JavaScriptのasync/awaitに関する備忘録になります。 「今まで$.Deferred()やPromiseなどで非同期処理は書いたことがあるが、async/awaitはわからない」 「$.Deferred()やPromiseなどの非同期処理の書き方より、もっと簡潔に書ける書き方があれば知りたい」 「今までの非同期処理の書き方と比べて何が良いのかわからない」 といった人達向けの記事です。 $.Deferred()やPromiseなどで非同期処理を書いたことがある前提のため、非同期処理自体に関する説明は記載しておりません。 記載している利用例のコードはChrome（最新）のコンソール上で動きますので、コンソール上で実行して動作を確認してみると理解が深まりやすいと思います。 本記事で用いている用語 Promiseを返す Promiseオブジェクトを返すこと。
はじめての Nuxt.js + Vuex + axios - Qiita
この記事について 下記のもくもく会でやりました。 【初心者・1人参加歓迎】ITプロラボ_Laravel / Vue.js もくもく会(Web系)#3 - connpass 普段は PHP でバックエンドのコードを書くことが多いですが、ここ １ 年くらいで急激にフロントエンド書く機会が増えてきているので、Vue.js + Vuex （ついでに最近注目されている Nuxt も） でなんかつくってみよう、という、いわゆるやってみた系の記事です。 概要 定番の TODO リストをつくります。 フロントエンドに Nuxt.js 、バックエンドに Laravel を使います。 環境 nuxt を入れると、vue, vuex の他、開発に必要なモジュールをまるっと入れてくれるので、後述する vue init をした後、 yarn install すれば、すぐに開発をスタートすることができます。 nuxt
VMに手を加えずRubyを高速化するJITコンパイラ「YARV-MJIT」の話 - k0kubun's blog
先日のRubyKaigi 2017のLTではLLVMベースのCRuby向けJITコンパイラLLRBの話をしました。 5分はちょっとJITの話をするには短かかったですね。 LLRBをふまえた、Cのコード生成への軌道修正 さて、上記の資料にある通り、CRubyのJITにおいてはメインの高速化対象が既に存在するCのコードになるため、 開発の早い段階でパフォーマンスにインパクトを持てるとすればLLVM Passの順番を変えるくらいで、 LLVM IRを直接生成しても最適化上のメリットがほとんどないのでその部分はMJIT と同じくCのコードを生成するように変更したい、という話をした*1。 で、LLRBはC拡張として作るべくちょっと不思議な努力をいろいろやっており、 それらの設計はやってみた結果(コアに直接変更を加えるのに比べ)デメリットの方が大きいと思ったので、 LLRBの失敗を全て生かしつつ、今回
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
