What are the advantages of using Bonjour in a program (vb.net), is it even possible? Couldn't I get the same end result using just what I program?
You could probably write it yourself. But:
It would take a lot of time and effort
You would need to test it
You would need to maintain it
Using a standard tested library generally results in a cheaper and more robust solution.
http://deusty.blogspot.com/2008/03/bonjour-for-net.html
Related
I am using couchdb and I need to stress test the db to make sure about performance limitation.
I have never done any sort of performance testing. So I decided to write a piece of code to do so:
import couchdb
couch= couchdb.Server('xxxxxxx')
db= couch["performance_test"]
doc={
"test": "test",
"db":"cocuh"
}
db.save(doc)
So this is just a beginning and I need to add a lot to it to have it working. For example in terms of benchmarks, measure ... I am not sure what to do. Before keep going and complete the code I want to make sure I am in the right path. Is it the best way to do so? or should I use a specific tool for it? any insight is appreciated
First you need to figure out what you're actually measuring -- concurrent read rates, write throughput etc.
There are lots of load testing frameworks around, for example Locust. Using an existing load testing tool gives you a lot of functionality you otherwise would ghave to implement yourself. Locust makes nice graphs etc.
There are also plenty of tools and libraries that can help you generate random test data, such as faker in Python.
What would be the absolute fastest possible way to write a string to the standard/console output on Windows? I'm interested in the solution for both null- and non-null-terminated strings.
WriteConsole is pretty much the fastest you can get. It's still inter-process call to win32csr (on Windows 7 it's different, but it is still IPC) using LPC, so don't expect performance to be something surprising.
2nd on the WriteConsole answer, you can write the entire screen in one call;
but also 2nd on what Austin says: having ultrafast console output as a requirement for an application sounds a bit strange to me.
Anyway if it's really a bottleneck, maybe use some kind of logging system and provide actual logging to the console a seperate thread?
Does anyone know how to use Win32's BitBlt() using Ruby? It seems like you need to use a destination DC (device context) and how can Ruby handle that? I use GetPixel() and it is really slow even to get 100 pixels (takes about 10 seconds). thanks.
Second Carl's other post: use win32 screenshot http://github.com/jarmo/win32screenshot
How about writing all of your image processing code in C++ as a Win32 executable and launching it as a separate process or calling into it from Ruby using the Win32API class? It makes sense to do it this way instead of writing a cludge in Ruby which will never perform as well.
I'd just like to note that I'm seeing a similar thing. GetPixel is exceedingly slow on Vista. I've determined that this is the case when you're using that Aero thing. If you set desktop theme to one of the "Classic" settings, it's fast again. And the OP's estimate of ~10 seconds is not wrong, believe it or not. It's really exceedingly slow.
I, too, am looking for a BitBlt in Ruby. I expect I'll need to figure it out/write it, but was hoping someone else has already posted an example.
I wouldn't go quite as far as Ed; chances are you only want to do some relatively simple and commonplace things that a normal GUI would do. For this, such libraries already exist and don't need to be written.
One example would be wxRuby.
I'm afraid I'm not familiar with it, but maybe it already offers some screen-grabbing utility methods.
I need to do some network bound calls (e.g., fetch a website) and I don't want it to block the UI. Should I be using NSThread's or python's threading module if I am working in pyobjc? I can't find any information on how to choose one over the other. Note, I don't really care about Python's GIL since my tasks are not CPU bound at all.
It will make no difference, you will gain the same behavior with slightly different interfaces. Use whichever fits best into your system.
Learn to love the run loop. Use Cocoa's URL-loading system (or, if you need plain sockets, NSFileHandle) and let it call you when the response (or failure) comes back. Then you don't have to deal with threads at all (the URL-loading system will use a thread for you).
Pretty much the only time to create your own threads in Cocoa is when you have a large task (>0.1 sec) that you can't break up.
(Someone might say NSOperation, but NSOperationQueue is broken and RAOperationQueue doesn't support concurrent operations. Fine if you already have a bunch of NSOperationQueue code or really want to prepare for working NSOperationQueue, but if you need concurrency now, run loop or threads.)
I'm more fond of the native python threading solution since I could join and reference threads around. AFAIK, NSThreads don't support thread joining and cancelling, and you could get a variety of things done with python threads.
Also, it's a bummer that NSThreads can't have multiple arguments, and though there are workarounds for this (like using NSDictionarys and NSArrays), it's still not as elegant and as simple as invoking a thread with arguments laid out in order / corresponding parameters.
But yeah, if the situation demands you to use NSThreads, there shouldn't be any problem at all. Otherwise, it's cool to stick with native python threads.
I have a different suggestion, mainly because python threading is just plain awful because of the GIL (Global Interpreter Lock), especially when you have more than one cpu core. There is a video presentation that goes into this in excruciating detail, but I cannot find the video right now - it was done by a Google employee.
Anyway, you may want to think about using the subprocess module instead of threading (have a helper program that you can execute, or use another binary on the system. Or use NSThread, it should give you more performance than what you can get with CPython threads.
I've been testing out the performance and memory profiler AQTime to see if it's worthwhile spending those big $$$ for it for my Delphi application.
What amazes me is how it can give you source line level performance tracing (which includes the number of times each line was executed and the amount of time that line took) without modifying the application's source code and without adding an inordinate amount of time to the debug run.
The way that they do this so efficiently makes me think there might be some techniques/technologies used here that I don't know about that would be useful to know about.
Do you know what kind of methods they use to capture the execution line-by-line without code changes?
Are there other profiling tools that also do non-invasive line-by-line checking and if so, do they use the same techniques?
I've made an open source profiler for Delphi which does the same:
http://code.google.com/p/asmprofiler/
It's not perfect, but it's free :-). Is also uses the Detour technique.
It stores every call (you must manual set which functions you want to profile),
so it can make an exact call history tree, including a time chart (!).
This is just speculation, but perhaps AQtime is based on a technology that is similar to Microsoft Detours?
Detours is a library for instrumenting
arbitrary Win32 functions on x86, x64,
and IA64 machines. Detours intercepts
Win32 functions by re-writing the
in-memory code for target functions.
I don't know about Delphi in particular, but a C application debugger can do line-by-line profiling relatively easily - it can load the code and associate every code path with a block of code. Then it can break on all the conditional jump instructions and just watch and see what code path is taken. Debuggers like gdb can operate relatively efficiently because they work through the kernel and don't modify the code, they just get informed when each line is executed. If something causes the block to be exited early (longjmp), the debugger can hook that and figure out how far it got into the blocks when it happened and increment only those lines.
Of course, it would still be tough to code, but when I say easily I mean that you could do it without wasting time breaking on each and every instruction to update a counter.
The long-since-defunct TurboPower also had a great profiling/analysis tool for Delphi called Sleuth QA Suite. I found it a lot simpler than AQTime, but also far easier to get meaningful result. Might be worth trying to track down - eBay, maybe?