p*****2
发帖数: 21240 | | p*****2
发帖数: 21240 | 2 还有就是有好的rest framework吗
【在 p*****2 的大作中提到】
: 是很高还是一般？
| d******e
发帖数: 2265 | 3 yeosd, wrap, snap
【在 p*****2 的大作中提到】
: 还有就是有好的rest framework吗
| p*****2
发帖数: 21240 | 4 貌似scotty更好？
【在 d******e 的大作中提到】
: yeosd, wrap, snap
| w******p
发帖数: 166 | 5 i wrote something to parse logs and then do something else, the log files is
less than 10k lines and it's slow like hell, optimized compiled code is way
slower than Perl. Not to mention that "functional" statement doesn't look
easier to read than perl.
I know that I'm hit by its lazy evaluation, and I tried to use foldr or
foldl' instead of foldl, etc. Haskell's lazy ass just doesn't seem to move
quickly. This is quite bad compared to my experience with Standard ML, which
produced code much faster than perl, and was what I have expected for
compiled code. | d******e
发帖数: 2265 | 6 Haskell‘s default string implemention is linked list. it is extremely slow.
is
way
which
【在 w******p 的大作中提到】
: i wrote something to parse logs and then do something else, the log files is
: less than 10k lines and it's slow like hell, optimized compiled code is way
: slower than Perl. Not to mention that "functional" statement doesn't look
: easier to read than perl.
: I know that I'm hit by its lazy evaluation, and I tried to use foldr or
: foldl' instead of foldl, etc. Haskell's lazy ass just doesn't seem to move
: quickly. This is quite bad compared to my experience with Standard ML, which
: produced code much faster than perl, and was what I have expected for
: compiled code.
| d******e
发帖数: 2265 | 7 没用过。二爷可以试试？
【在 p*****2 的大作中提到】
: 貌似scotty更好？
| w******p
发帖数: 166 | 8 In Standard ML I also treat them as linked list, using explode/implode,
still much faster.
Lazy eval is evil in prod env. for Haskell, that's why parallel Haskell don'
t use lazy eval at all.
slow.
【在 d******e 的大作中提到】
: Haskell‘s default string implemention is linked list. it is extremely slow.
:
: is
: way
: which
| w***g
发帖数: 5958 | 9 lazy eval是为了写所谓漂亮的functional代码引入的伪问题。
lazy eval起作用的前提就是写了实际上不会被运行到的代码。
imperative programming里面很少有写了不用的代码。
don'
【在 w******p 的大作中提到】
: In Standard ML I also treat them as linked list, using explode/implode,
: still much faster.
: Lazy eval is evil in prod env. for Haskell, that's why parallel Haskell don'
: t use lazy eval at all.
:
: slow.
| w******p
发帖数: 166 | 10 I think lazy eval is okay, but it shouldn't be the default, whoever want to
have lazy eval just do their own thunks, and with any language that supports
pointer/reference.
By making it the default really confuses people about performance, and
invents problem that wasn't there before.
However, lazy eval seems essential for Haskell because it wants to be "pure"
, in that the function parameter evaluation orders doesn't matter for
deterministic calculations, and at the same time save duplicated evaluations
like calculation "a+b" twice in square(a+b) => (a+b) * (a+b), therefore
making a pointer/thunk for "a+b" calculation and don't do it unless needed.
Yes, Haskell is "powerful" because of this, it can implement cool things
like if_then_else with short circuits with a function -- that other
languages like lisp/ml/java/c/etc cannot do -- they all have to eval all
args before calling a function and therefore cannot short circuit. But in
the end, how useful is lazy eval other showing off with cool tricks? | | | a*****e
发帖数: 1700 | 11 我最喜欢这类问题了，你方便贴一下代码么？
is
way
which
【在 w******p 的大作中提到】
: i wrote something to parse logs and then do something else, the log files is
: less than 10k lines and it's slow like hell, optimized compiled code is way
: slower than Perl. Not to mention that "functional" statement doesn't look
: easier to read than perl.
: I know that I'm hit by its lazy evaluation, and I tried to use foldr or
: foldl' instead of foldl, etc. Haskell's lazy ass just doesn't seem to move
: quickly. This is quite bad compared to my experience with Standard ML, which
: produced code much faster than perl, and was what I have expected for
: compiled code.
| a*****e
发帖数: 1700 | 12 lazy vs strict 这个问题，基本的 facts 都总结在这两个文章里面：
http://existentialtype.wordpress.com/2011/04/24/the-real-point-
第一篇是 Bob Harper 写的，学过 SML 的应该都知道他吧，估计没有人比他更痛恨
Haskell 了，呵呵。文章讲到的都很有道理，没讲到的我觉得应该是故意略过了。所以
要看第二篇。
http://augustss.blogspot.com/2011/05/more-points-for-lazy-evalu
第二篇是 Lennart Augustsson 写的，早期 Haskell 的重要功臣之一，他在 Standard
Chartered 写的内部用的 mu haskell 是 strict by default。他这个文章讲了几点
laziness 的好处，就算是 Harper 也不好反驳。
don'
【在 w******p 的大作中提到】
: In Standard ML I also treat them as linked list, using explode/implode,
: still much faster.
: Lazy eval is evil in prod env. for Haskell, that's why parallel Haskell don'
: t use lazy eval at all.
:
: slow.
| w******p
发帖数: 166 | 13 sure here's the code, i want to get a map from the log lines, with the 2nd
or 3rd record as key. You see that I try to make it quicker by only getting
first 30 chars of each line because I know that the keys cannot be too long,
and I filter out empty lines and short lines with less than 50 words. In
practice the `isInfixOf` filtering did speed up the parsing by about 1x or
2x.
parseLog candidates = readFile "records" >>= buf ->
return $ foldl' (accu -> x->
let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
in (x!!1,v):(x!!2,v):accu
) [] $ filter (x->length x>50) $ map words $ filter (line->
any (c->((' ':c)++" ") `isInfixOf` (take 30 line)
) candidates
) $ lines buf
above code is much harder to read and much slower than perl's simple
(split)[1,2,29,27,32,33,49]
【在 a*****e 的大作中提到】
: 我最喜欢这类问题了，你方便贴一下代码么？
:
: is
: way
: which
| a*****e
发帖数: 1700 | 14 你那行 perl 显然做的不是同一件事情。如果做和 perl 同样的事情，以下是 Haskell
程序：
main = parse >>= mapM_ (putStrLn . show)
parse = readFile "records" >>= return . concat . map (takeOut . words) .
lines
where
takeOut x = let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
in [(x!!1,v), (x!!2,v)]
以下是 Perl 程序：
my $filename = "records";
open (my $fh, $filename)
or die ("could not open file '$filename'");
while (my $row = <$fh>) {
my @x = (split(/ /, $row))[1,2,29,27,32,33,49];
print "($x[1], @x)\n";
print "($x[2], @x)\n";
}
基本上做的是同一件事情。我用 100K 行输入，perl 2秒，haskell 4秒。
考虑到 Haskell 用的是 default String，这个 performance not too shabby.
如果用 ByteString，就和 perl 速度一样。而且 Haskell 里面 !! 还是在用 linked
list 而 Perl 里面取下标是数组。
而且无论你用什么语言，想要优化，总是有空间。
我的意思是，上面那个 Haskell 程序效率方面完全可以接受，一行程序也不难读。
getting
long,
【在 w******p 的大作中提到】
: sure here's the code, i want to get a map from the log lines, with the 2nd
: or 3rd record as key. You see that I try to make it quicker by only getting
: first 30 chars of each line because I know that the keys cannot be too long,
: and I filter out empty lines and short lines with less than 50 words. In
: practice the `isInfixOf` filtering did speed up the parsing by about 1x or
: 2x.
: parseLog candidates = readFile "records" >>= buf ->
: return $ foldl' (accu -> x->
: let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
: in (x!!1,v):(x!!2,v):accu
| w******p
发帖数: 166 | 15 your input is definitely different than mine, my log lines are all very long
, thousands of chars each line.
with Perl I don't need to do the filtering to check if the search candidates
are within the first 30 chars, with Haskell I have to make code much more
lengthy and harder to read to try to be on par with Perl.
同样的事情 for me is to get my result as soon as could be operating on my
long log-line files, perl one line vs. Haskell multi-line ugliness I had to
do -- perl one-liner sufficient, and in the end perl wins in 生产环境的生产
力, be it coding speed or code execution speed.
with SML I don't need to do that ugly filtering and it's faster than perl.
make no mistake I like Haskell because it broadens one's horizon.
One more bad thing about Haskell though: its code must be formatted with
proper indentation, like Python but much worse than Python, Python's is much
simpler rule, Haskell's is much more unpredictable. Whenever I just do a
simple thing like changing a function name to be longer, the indentation
breaks and I had to adjust every freaking lines in the function manually! If
Python indentation annoys people, Haskell's is just pure pure evil. With
Emacs I can simply press tab to make Python indentation right, I tried 3
Emacs haskell plugins, none can make it right all the time.
Haskell
【在 a*****e 的大作中提到】
: 你那行 perl 显然做的不是同一件事情。如果做和 perl 同样的事情，以下是 Haskell
: 程序：
: main = parse >>= mapM_ (putStrLn . show)
: parse = readFile "records" >>= return . concat . map (takeOut . words) .
: lines
: where
: takeOut x = let v = (x!!1,x!!2,x!!29,x!!27,x!!32,x!!33,x!!49)
: in [(x!!1,v), (x!!2,v)]
: 以下是 Perl 程序：
: my $filename = "records";
| a*****e
发帖数: 1700 | 16 重点在于要用 ByteString，而不是你那个 30 字符 prefix match 的优化（而且吧，
你那个优化其实效率很差，因为你还在用 list）。你不能指望 linked list 和 Perl
或者 SML 的 array based String 一个效率。
至于缩进，我觉得你还是没理解它的设计要素，我从来没有遇到过你说的手工改动多行
的情况。如果实在不喜欢，可以直接用 { 和 } 和 ; 然后就和写 C 一样了，完全不需
要理会缩进规则。GHC 编译器里面有不少代码都是这种格式写的，也没什么啊
long
candidates
to
【在 w******p 的大作中提到】
: your input is definitely different than mine, my log lines are all very long
: , thousands of chars each line.
: with Perl I don't need to do the filtering to check if the search candidates
: are within the first 30 chars, with Haskell I have to make code much more
: lengthy and harder to read to try to be on par with Perl.
: 同样的事情 for me is to get my result as soon as could be operating on my
: long log-line files, perl one line vs. Haskell multi-line ugliness I had to
: do -- perl one-liner sufficient, and in the end perl wins in 生产环境的生产
: 力, be it coding speed or code execution speed.
: with SML I don't need to do that ugly filtering and it's faster than perl.
| w******p
发帖数: 166 | 17 ByteString 好像不好用啊，读zip文件得用Data.ByteString.Lazy，但是用的是GHC.
Word.Word8,跟Char转换挺费劲的，我需要一个统一的interface既能读一般文件，又能
读zip文件，Data.ByteString.Lazy跟Data.ByteString.Lazy.Char8又不兼容，看来
haskell是kill time利器啊 | a*****e
发帖数: 1700 | 18 绝对的 kill time 利器 :-)
ByteString.Lazy 和 ByteString.Lazy.Char8 怎么会不兼容呢，后者是为前者提供向
Char 转化的工具（直接 truncate），但是操作的结果和对象可都是 ByteString.Lazy
啊。所以你用 Codec.Archive.Zip 读写的 ByteString.Lazy.ByteString 类型的值，
直接用 ByteString.Lazy.Char8 里面的函数操作即可。
不过说实在话，我不知道你为什么喜欢用 Char，直接用 Word8 并没有很不方便。
尤其是 String literal 可以直接使用 {-# LANGUAGE OverloadedStrings #-}
如果你说的是 ByteString 和 [Char] 之间转换，只需要用到 ByteStirng.Lazy.Char8
.pack 和 unpack 两个函数，其它不需要考虑。如果你需要 UTF8 编码转换，用 utf8-
string 这个库。
【在 w******p 的大作中提到】
: ByteString 好像不好用啊，读zip文件得用Data.ByteString.Lazy，但是用的是GHC.
: Word.Word8,跟Char转换挺费劲的，我需要一个统一的interface既能读一般文件，又能
: 读zip文件，Data.ByteString.Lazy跟Data.ByteString.Lazy.Char8又不兼容，看来
: haskell是kill time利器啊
| w******p
发帖数: 166 | 19 谢谢高手解答，不过我得去看看别的啥透透气去，过几天再来看haskell吧，想提高提
高效率这么多trick |
|
