Tag Info

New answers tagged

0

Optimisation (besides micro-optimization) is directly at odds with modularity. Modularity works by isolating code from it's global context, whereas performance optimization exploits global context to minimise what the code has to do. Modularity is the benefit of low-coupling, whereas (the potential for) very high performance is the benefit of high-coupling. ...


1

For a long time, I used to implement a complicated system of checks to be able to use database transactions. The transaction logic goes as follows: open a transaction, perform the database operations, rollback upon error or commit on success. The complication comes from what happens when you want an additional operation to be performed within the same ...


5

Neither of these seems more reusable than the other. They just seem to be at different abstraction levels. The first is for calling code that understands the stock system intimately enough to know that validating a stock reference means looking through a Recordset with some kind of query. The second is for calling code that just wants to know whether a stock ...


1

2 functions: one opens the recordset and passes it to a data analysis function. The first can be bypassed if you already have an open recordset. The second can assume that it will be passed an open recordset, ignoring where it came from, and process the data. You have both performance and re-usability then!


2

You could have two overloaded functions. That way you can use both of them according to the situation. You can't never (I've never seen it happen) optimize for everything, so you got to settle for something. Choose what you believe is more important.


10

You should do whatever yields the greater business value in this situation. Writing software is always a trade-off. Almost never are all valid goals (maintainability, performance, clarity, conciseness, security etc. etc.) completely aligned. Do not fall into the trap of those short-sighted people who consider one of these dimensions as paramount and tell ...


0

The implementations I've seen from others, and the ones I've written for myself, have always had the ants release the pheromones along the path the traveled to get to food, once they have reached the food. That is, the ants march from their colony to the food following a random walk; the paths followed by the ants from the colony to the food are then marked ...


3

This isn't how ACO works. ACO only drops pheromones after ants have moved across all the points in the grid. You then evaluate something (perhaps total travel time) and then drop pheromones for good ants, and repeat. They don't move to the same vertex twice, generally, though you can customize this for implementation specificness. Pheromones aren't ...


6

Does the ML (SML/F#) implementations of tco in these languages differ substantially from the implementation in other languages, such as C++ and Haskell? Not as far as I know, no. The optimization of discarding the existing stack rather than saving off its current state (and possibly adjusting the execution pointer directly) on the last function call in ...


1

Elevator algorithm is best described using Knuth's Elevator algorithm. But in the simple steps, the algorithm can be stated as: Travel in the single direction until the last request in that direction. If there is no request, stop and proceed towards other direction, if there is any request from other direction.


0

It depends who you are selling your software product to. More often then not, your customer is not the end /day to day user. So often you end up with making more nice and shiny reports instead of fixing performance issues. Because really you're selling to management, not end user. Which means in that case, you will be hard pressed to mark up for some ...



Top 50 recent answers are included