TEST[SyncClient]: Processed 1000 requests in 43 seconds!
TEST[DeprecatedAPI]: Processed 1000 requests in 0 seconds!
TEST[ApacheBenchmark]: Processed 1000 requests in 0 seconds!
Same results here..Sync is very slow
Some greps can indeed be quite good.
Really, I think this algorithmic intelligence should be able to be just used
from Nim `strutils`. Nim strings know their length. Many/most of those
read-only procs like `strutils.find` "should" be able to work on types like
`MemSlice` or really some kind of
> Won't raise an exception for EOF.
Nor should it, EOF is only raised if the proc interface was so poor it couldn't
signal it in any other way. Eventually we will get `io.nim` that uses a proper
sum type for this.
> I guess 3. could be a function like your checkErr() but then it should always
I don't want to file an issue, because maybe the problem is in my code. Below
is the minimal test (also available [as
gist](https://gist.github.com/vegansk/8d4126fa5205f1d86145891b02467f46)).
So, the problem is that if I use deprecated API from httpclient, I get maximum
performance while produc
@Araq
So, I read the version from:
[https://github.com/nim-lang/Nim/blob/devel/lib/system/sysio.nim](https://github.com/nim-lang/Nim/blob/devel/lib/system/sysio.nim)
I hope that was the right one.
proc checkErr(f: File) =
if c_ferror(f) != 0:
c_clearerr(f)
rai
I ran your code and I got consistent result with SyncClient faster than
DeprecatedApi.
I've ran it in Windows 10 (gcc-mingw64, withouth ab), and Linux subsystem, all
results are consistent.
When I ran a debug build, I got this stack of errors:
Traceback (most recent call last)
random_art.nim(185) random_art
equationParser.nim(51) parseEquation
equationParser.nim(73) buildEquation
ModExpr.nim(72) buildMod
equationParser.nim(75) buil
@BossHogg The IO routines have been fixed but I wouldn't mind another pair of
eyes on the code.
Yeah. I haven't tried out your code, but an API idea might be to have the
caller instruct the iterator what to do with any improper/undelimited record at
the end -- includeUnterminated=False or something. Only the caller really knows
what is desired.
One observation, algo performance-wise, is t
I don't have the crash report. In the stack trace there might be information
that helps to solve this problem.
> Anyway, this idea is just sort of the simplest/first step into a wider world
> of efficient substring search algorithms that you might enjoy reading about
> some day.
Mmmyeah... or I'll call `grep` (seriously, I did it for another program because
it was faster than my lousy simplistic algorit
11 matches
Mail list logo
