If you do ^t just after spawn, you are effectively not using the worker thread
as the UI thread is blocked waiting the worker thread to finish.
What you should do is to spawn a thread and inside the worker thread notify the
UI thread that "t" is ready, so UI thread can then update "textArea".
> i wanted to use Option[T] which were removed anyway because it made the code
> 5x slower
Doing exactly the same thing (but taking a rust port as a reference), I also
had the same problem with Option[T] as return type being 3.5x slower than
(bool, T) tuple on some cases but not others. :(
I have been using nim for at least 2 years, doing some simple tools (console
and ui with libui) for the company I work for. Also I enjoy programming some
PoCs here and there in github.
I am really happy coding with nim, that is the best nim feature, developer
happiness.
Nim and its core
It happened!!! Congrats!!! Long life to this wonderful language.
Yes you are right. I was thinking about type definiton while the question was
about variable definition. Thanks.
Use var sdl_rect : Rect If you ate going to process a lot of them sequentially.
Use var sdl_rect : ref Rect If you only handle those instances individually or
if you use OOP or if there is a lot of fields (data) in the object
If performance is the reason to avoid allocations, my suggestion is to allocate
some initial amount which will be good for 99% of use cases and if that initial
amount is reached and maxFD is bigger, reallocate one more time the full maxFD
and copy from initial seq. This allocation will only
Ok, i have found why:
In that commit there is a new templated implementation for newSelector()
(0.17.2) to newSelector[T]() (0.17.3+) in linux specifically it is using epoll.
proc newSelector*[T](): Selector[T] =
# Retrieve the maximum fd count (for current OS) via
Found, big commit, but i will check it
d3394be5559c324da1c6b576d0ae9bfa966698d9 is the first bad commit
commit d3394be5559c324da1c6b576d0ae9bfa966698d9
Author: Dominik Picheta
Date: Wed Nov 22 14:43:10 2017 +
Async upcoming (#6585)
I am thinking about bisecting it now that I have a simple test. Also now I have
a Dockerfile to bootstrap any commit
FROM alpine
RUN apk add --no-cache g++ curl tar git
RUN git clone https://github.com/nim-lang/Nim.git;
RUN cd Nim; \
git clone --depth 1
For anyone interested I found that:
import asyncdispatch, asyncnet, os
var server = newAsyncSocket() #or newAsyncNativeSocket()
let x = readFile("/proc/self/status")
echo x
Uses 44MB with 0.18.x
Uses 4MB with 0.17.2
indeed no changes:
sudo pmap 28234
28234: ./httpasync0181
561967f7a000124K r-x-- httpasync0181
561968198000 4K r httpasync0181
561968199000 4K rw--- httpasync0181
56196819a000 32K rw--- [ anon ]
561968b41000
Thanks Araq, right now I am using "clients" to avoid deallocating memory, so
that I can get peak memory use. In the future, it will be used to dispatch
messages to specific connected clients. This service should also remove clients
from that sequence when they disconnect. Sorry, I will try to
I have done a little test to find out if I could run some microservices with
async code in memory constrained devices. Here is the test code:
[https://gist.github.com/aguspiza/80e34b5cf65aa3bbfd19c7339ee9b695](https://gist.github.com/aguspiza/80e34b5cf65aa3bbfd19c7339ee9b695)
That test uses 5x
14 matches
Mail list logo
